Daily updates from Odoo
Navigate
Branch
Tuesday, March 26, 2024
92 changes
25 changes
Miscellaneous changes
Description of the issue/feature this PR addresses: the autoreload does not work after modified python file(s), dev reload mode has been eanbled when start odoo on windows 11. i found the reason is: when a file modified, watchdog event has the property 'dest_path' but content is empty Current behavior before PR: odoo started with --dev=reload, the log show watchdog is watching addon folders but when i modified a python file, the odoo app did not restart, the log has no output. Desired
Original PR description
Description of the issue/feature this PR addresses: the autoreload does not work after modified python file(s), dev reload mode has been eanbled when start odoo on windows 11. i found the reason is: when a file modified, watchdog event has the property 'dest_path' but content is empty Current behavior before PR: odoo started with --dev=reload, the log show watchdog is watching addon folders but when i modified a python file, the odoo app did not restart, the log has no output. 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#157829
**Steps to reproduce:** - Install Accounting and Purchase - Go to Purchase and create a PO: * Vendor: Vendor X * Product: Product X * Unit Price: 50.00 - Create an electronic bill in XML format with: * a reference to PO name * the same partner than the PO * the same line than the PO, except for the price - Go to "Accounting / Vendors / Bills" - Upload the XML bill **Issue:** The bill is generated and linked to the PO, but the price and subtotal on the bill line is the
Original PR description
**Steps to reproduce:** - Install Accounting and Purchase - Go to Purchase and create a PO: * Vendor: Vendor X * Product: Product X * Unit Price: 50.00 - Create an electronic bill in XML format with: * a reference to PO name * the same partner than the PO * the same line than the PO, except for the price - Go to "Accounting / Vendors / Bills" - Upload the XML bill **Issue:** The bill is generated and linked to the PO, but the price and subtotal on the bill line is the one coming from the PO instead of the one coming from the XML. Values coming from an imported XML should not be overridden by values found in matching PO. **Cause:** "timeout" parameter is wrongly passed as "prefer_purchase_line" parameter in a call to "_find_and_set_purchase_orders" method. opw-3707731 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#158015
Reversing an invoice wizard provides an option to use the original entry date, but does not set the invoice_date to the same date. This behaviour is strange because the UI displays today's date, but the move is actually posted on a different date. This commit, keeps the dates in sync. Source: https://github.com/odoo/odoo/pull/93609 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#158640 Forward-Port-Of: odoo/odoo#1
Original PR description
Reversing an invoice wizard provides an option to use the original entry date, but does not set the invoice_date to the same date. This behaviour is strange because the UI displays today's date, but the move is actually posted on a different date. This commit, keeps the dates in sync. Source: https://github.com/odoo/odoo/pull/93609 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#158640 Forward-Port-Of: odoo/odoo#158530
The underlying `odoo.tools.email_send` was removed in 82de620424e22f9ca7cb9768db638c3a2b4f9318 (merged in 14.5) but this callsite was missed, this method has been broken ever since. Forward-Port-Of: odoo/odoo#159113
Original PR description
The underlying `odoo.tools.email_send` was removed in 82de620424e22f9ca7cb9768db638c3a2b4f9318 (merged in 14.5) but this callsite was missed, this method has been broken ever since. Forward-Port-Of: odoo/odoo#159113
STEP TO REPRODUCE : =================== - Select only one company - Write "marc demo" in employee search bar You will see two Marc Demo for manager line. task : 3716448 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#155345
Original PR description
STEP TO REPRODUCE : =================== - Select only one company - Write "marc demo" in employee search bar You will see two Marc Demo for manager line. task : 3716448 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#155345
In some edge cases the invoice date will differ from the accounting date. This commit makes sure that when this is the case the accounting date is shown on a posted invoice or credit note. This way it stays clear that the accounting date differs from the invoice date. task: 3774329 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#156315
Original PR description
In some edge cases the invoice date will differ from the accounting date. This commit makes sure that when this is the case the accounting date is shown on a posted invoice or credit note. This way it stays clear that the accounting date differs from the invoice date. task: 3774329 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#156315
**Current behavior:** Trying to select the Algerian fiscal localization for a company after installing the respective module is impossible. **Expected behavior:** The localization package should be installable after the module has been installed. **Steps to reproduce:** 1. Install `l10n_dz` and create a new company without any fiscal localization 2. In the fresh company, select `Algeria` as the fiscal localization package, observe the error **Cause of the issue:** Two tax names i
Original PR description
**Current behavior:** Trying to select the Algerian fiscal localization for a company after installing the respective module is impossible. **Expected behavior:** The localization package should be installable after the module has been installed. **Steps to reproduce:** 1. Install `l10n_dz` and create a new company without any fiscal localization 2. In the fresh company, select `Algeria` as the fiscal localization package, observe the error **Cause of the issue:** Two tax names in the module's tax data file have the same values for a field that should be unique. **Fix:** Change the values in the identical fields. opw-3787096 Forward-Port-Of: odoo/odoo#157198
*: website, website_twitter This commit introduces an update to the Font Awesome library, specifically replacing the X/Twitter icon with its new design. It also involves adjustments to a few images and SVG files to incorporate the updated X/Twitter logo. Technical note: It updates an existing file, originally modified for the addition of the TikTok icon, which was not available in Font Awesome 4. Related to: https://github.com/odoo/enterprise/pull/53644 task-3463530 --- I con
Original PR description
*: website, website_twitter This commit introduces an update to the Font Awesome library, specifically replacing the X/Twitter icon with its new design. It also involves adjustments to a few images and SVG files to incorporate the updated X/Twitter logo. Technical note: It updates an existing file, originally modified for the addition of the TikTok icon, which was not available in Font Awesome 4. Related to: https://github.com/odoo/enterprise/pull/53644 task-3463530 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#158586 Forward-Port-Of: odoo/odoo#148126
Issue ----- The sale confirmation mail template is not rendered because a part of code is translated. Note: there's currently no Norwegian translation on Transifex for this version opw-3809578 Forward-Port-Of: odoo/odoo#158770
Original PR description
Issue ----- The sale confirmation mail template is not rendered because a part of code is translated. Note: there's currently no Norwegian translation on Transifex for this version opw-3809578 Forward-Port-Of: odoo/odoo#158770
The fields in analytic have a group which is defined in account. It's okay to show them in analytic module only (for example from project) for people having the rights to see analytic. We also show balance now, even if you don't have the group 'readonly', because it's an information that is independent of credit/debit notion. Linked to runbot error 59222 (will need to remove the group in the test) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com
Original PR description
The fields in analytic have a group which is defined in account. It's okay to show them in analytic module only (for example from project) for people having the rights to see analytic. We also show balance now, even if you don't have the group 'readonly', because it's an information that is independent of credit/debit notion. Linked to runbot error 59222 (will need to remove the group in the test) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#158994 Forward-Port-Of: odoo/odoo#156349
This prevents a traceback\* which happens when the webrtc connection is under signaling stress and a local rollback is triggered when the state has been set back to stable. This seems to be caused by browser bugs (both in [Firefox](<https://bugzilla.mozilla.org/show_bug.cgi?id=1628139>) and in [Chromium](<https://issues.chromium.org/issues/40132342>) due to an [error](<https://github.com/w3c/webrtc-pc/issues/2508>) in the webrtc spec) that occur under stress. To prevent this sort of issue, a
Original PR description
This prevents a traceback\* which happens when the webrtc connection is under signaling stress and a local rollback is triggered when the state has been set back to stable. This seems to be caused by…
This prevents a traceback\* which happens when the webrtc connection is under signaling stress and a local rollback is triggered when the state has been set back to stable. This seems to be caused by browser bugs (both in [Firefox](<https://bugzilla.mozilla.org/show_bug.cgi?id=1628139>) and in [Chromium](<https://issues.chromium.org/issues/40132342>) due to an [error](<https://github.com/w3c/webrtc-pc/issues/2508>) in the webrtc spec) that occur under stress. To prevent this sort of issue, a solution was provided in the form of an [implicit rollback](<https://developer.mozilla.org/en-US/docs/Web/API/RTCPeerConnection/setRemoteDescription#browser_compatibility>) on the remote description setter. This solution has recently become available everywhere (since Safari adopted it in [2022](<https://caniuse.com/mdn-api_rtcpeerconnection_setremotedescription_implicit_rollback>) for desktop and iOS). This allows us to simply rely on the remote description setter to handle the rollback if needed. \* Traceback: InvalidStateError: Cannot rollback local description in stable. task-3823100 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#158861
In Inventory Settings activate packages and storage locations. Create a storable product [TEST] with tracking by lot Create a PO for [TEST] with a [QTY] larger than one. Receive the products (lot [A]) and put them in a package [PKG]. Create and process an internal transfer of the whole package [PKG] from the input location to any location. Unpack [PKG]. Go to Stock > Reporting > Locations Locate the received product, hit 'History' Issue: traceability is empty. This occurs because t
Original PR description
In Inventory Settings activate packages and storage locations. Create a storable product [TEST] with tracking by lot Create a PO for [TEST] with a [QTY] larger than one. Receive the products (lot [A]) and put them in a package [PKG]. Create and process an internal transfer of the whole package [PKG] from the input location to any location. Unpack [PKG]. Go to Stock > Reporting > Locations Locate the received product, hit 'History' Issue: traceability is empty. This occurs because the 'unpack' operation clean the information relative to the package from the stock quant. When accessing the history, the system lookup for move lines having the same package (none in this case), so nothing is found opw-3769752 Forward-Port-Of: odoo/odoo#158949 Forward-Port-Of: odoo/odoo#158410
Since [this other commit], the style indicating the active nav item stopped working if the user added record pages to the navbar. This was due to the cache system not being invalidated when switching from one record page to another. This commit fixes the issue by disabling the cache for the navbar if there is a record page in the menu. Other potential solutions were considered but ultimately rejected: 1. Using the record as a t-cache key. However, this would mean that if you have 60,
Original PR description
Since [this other commit], the style indicating the active nav item stopped working if the user added record pages to the navbar. This was due to the cache system not being invalidated when switching…
Since [this other commit], the style indicating the active nav item stopped working if the user added record pages to the navbar. This was due to the cache system not being invalidated when switching from one record page to another. This commit fixes the issue by disabling the cache for the navbar if there is a record page in the menu. Other potential solutions were considered but ultimately rejected: 1. Using the record as a t-cache key. However, this would mean that if you have 60,000 visible forum posts, you would end up with 60,000 different caches. 2. Activate the correct element using JavaScript. This would lead to a duplicate logic in the JavaScript and the Python code, and it would introduces a slight lag to add the active class on the correct nav item (due to the time it takes to load and execute the JavaScript). The chosen solution is the best compromise, as it maintains the cache for most cases (website menu without records page links in it), nothing change with this commit. For problematic cases (record pages in the website menu), this commit disables the cache, which is a reasonable trade-off. Steps to reproduce the bug fixed by this commit: - Edit a website's menu - Add a link to a product page (e.g., customizable-desk) - Add a link to another product (e.g., chair-floor-protection) - Save the menu - Click on the menu link to go to customizable-desk => At this point, the active menu element is correct - Click on the menu link to go to chair-floor-protection => The active menu element does not update This commit fixes the issue (a update of the website module is needed) and adds a test to prevent regressions. Notes: - To see the issue locally, remove the --dev xml or --dev all arguments. - The same issue was occurring with other record pages (blog posts, ..). [this other commit]: https://github.com/odoo/odoo/commit/b0a2a41d78292cb8b9e53788d40c6dc5915a466d opw-3694651 opw-3750925 opw-3781668 Forward-Port-Of: odoo/odoo#159080 Forward-Port-Of: odoo/odoo#154358
Before this commit, when a user of in chat posted a message and deleted it, all other users kept the chat as unread. Steps to reproduce: - Connect as Admin and March Demo - Send a message to Admin as Demo in DM chat - Demo deletes this message - Marc opens the chat => the unread counter is 1 and cannot be removed This happens because when a message is deleted, there's still a trace of it but the message is empty. However, empty messages could not be candidate of setting the last messag
Original PR description
Before this commit, when a user of in chat posted a message and deleted it, all other users kept the chat as unread. Steps to reproduce: - Connect as Admin and March Demo - Send a message to Admin as Demo in DM chat - Demo deletes this message - Marc opens the chat => the unread counter is 1 and cannot be removed This happens because when a message is deleted, there's still a trace of it but the message is empty. However, empty messages could not be candidate of setting the last message being seing by a member, thus members were unable to mark the chat as read until someone else posted a newer message (and did not delete it). This commit fixes the issue by taking empty messages into account for setting last message message of member, which allow to mark thread as read even when newer messages have been deleted. opw-3764410 Forward-Port-Of: odoo/odoo#159104 Forward-Port-Of: odoo/odoo#158943
36e6728b2cac87c7cd922001be0222688ad52abb fixed an issue where the volume and weight were incorrectly computed for carriers based on rules. But it was done by changing the method api, which seems to break some custom modules using/extending the modified methods. This commit reverts the API change, conveying the needed information through the context for now (the api change will be done in master only). opw-3826165 --- I confirm I have signed the CLA and read the PR guidelines at
Original PR description
36e6728b2cac87c7cd922001be0222688ad52abb fixed an issue where the volume and weight were incorrectly computed for carriers based on rules. But it was done by changing the method api, which seems to break some custom modules using/extending the modified methods. This commit reverts the API change, conveying the needed information through the context for now (the api change will be done in master only). opw-3826165 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#159181 Forward-Port-Of: odoo/odoo#159091
Create a Loyalty program: - Program Type: Loyalty Cards - Rules: 0.01 per $ spent - Reward: 1.00 per point on cheapest product Make a SO with total 339 Loyalty Card will get 3.39 points Make a SO with line having - Unit Price 140 - Tax 15% - Total will be 161 Hit Promotions Issue: The system will add a discount line with unit price 5.0. With 15% taxes applied the total discount will be 5.75 While it should be 5 Order 1, Total with tax 339 => 3.39 loyalty points Order 2, Tot
Original PR description
Create a Loyalty program: - Program Type: Loyalty Cards - Rules: 0.01 per $ spent - Reward: 1.00 per point on cheapest product Make a SO with total 339 Loyalty Card will get 3.39 points Make a SO with line having - Unit Price 140 - Tax 15% - Total will be 161 Hit Promotions Issue: The system will add a discount line with unit price 5.0. With 15% taxes applied the total discount will be 5.75 While it should be 5 Order 1, Total with tax 339 => 3.39 loyalty points Order 2, Total with tax 161 => 1.41 loyalty points from current order \+ 3.39 from past order = 5.00 total loyalty points When applying the discount on Order 2 the system converts 5 points to 5$, but considering 15% tax included, the price unit of the discount line should be 4.35 opw-3642795 Forward-Port-Of: odoo/odoo#157125
Commit [1] introduced new image settings for the product page. When those settings were introduced,the editor was reloaded after the RPC to properly reflect when the settings were changed. While this was done, a data-reload was also added in the XML template of the options. This was not necessary as the data-reload only works for some methods which are not used in the image settings. Therefore, the data-reload did nothing. However, with commit [2], the settings were moved and combined with pa
Original PR description
Commit [1] introduced new image settings for the product page. When those settings were introduced,the editor was reloaded after the RPC to properly reflect when the settings were changed. While this…
Commit [1] introduced new image settings for the product page. When those settings were introduced,the editor was reloaded after the RPC to properly reflect when the settings were changed. While this was done, a data-reload was also added in the XML template of the options. This was not necessary as the data-reload only works for some methods which are not used in the image settings. Therefore, the data-reload did nothing. However, with commit [2], the settings were moved and combined with page options. So the image settings automatically inherited the page options behavior, which is to save and reload the page when a method with data-reload is called. This caused the editor to ask for a reload twice. This did not cause a problem as somehow, the second reload was ignored. But with the conversion of the SnippetsMenu to OWL, it seems like the race condition introduces an error. This commit fixes the behavior by removing the reload request after applying image settings. [1]: https://github.com/odoo/odoo/commit/54c6d36cfbea31fe60b888bbb903b0c6f22216b3 [2]: https://github.com/odoo/odoo/commit/b274cf2427951761e59eb357fb796b54be375507#diff-754f6c793d6a168d006d2a9da108142b889036031ac1a2e62060c225d060f858 Forward-Port-Of: odoo/odoo#159169 Forward-Port-Of: odoo/odoo#156658
Steps to reproduce: - Go to website in "Edit" mode (on a blog post page). - Select one of the default images in the blog content. - Click on the "Animation" option and select "On Hover" > Traceback! Starting from [1], the "On hover" image animation was implemented to be able to pick an animation that triggers when hovering an image. This feature is setting a default "Square" shape (required for the hover effects to work) on the target. Which means that an error can always occur if t
Original PR description
Steps to reproduce: - Go to website in "Edit" mode (on a blog post page). - Select one of the default images in the blog content. - Click on the "Animation" option and select "On Hover" > Traceback! Starting from [1], the "On hover" image animation was implemented to be able to pick an animation that triggers when hovering an image. This feature is setting a default "Square" shape (required for the hover effects to work) on the target. Which means that an error can always occur if the "On Hover" animation option is available while the targeted image is not linked to an attachment and can't support image shapes (which is the case here). The goal of this commit is to fix this issue by only allowing the "On Hover" animations when it's possible to apply shapes to the image. [1]: https://github.com/odoo/odoo/commit/7f730f81ec541cc7791fc6b3fded17c838433f85 opw-3795599 Forward-Port-Of: odoo/odoo#158433
Bug === 1. login as demo user 2. add a review on a course and upload an attachment 3. click on the attachment link => You get a 404 error For some reason, we do not return the access token if the user is internal. The generation is not a heavy process, and might be needed depending on the <ir.rule>. Task-3693072 Forward-Port-Of: odoo/odoo#159126 Forward-Port-Of: odoo/odoo#156659
Original PR description
Bug === 1. login as demo user 2. add a review on a course and upload an attachment 3. click on the attachment link => You get a 404 error For some reason, we do not return the access token if the user is internal. The generation is not a heavy process, and might be needed depending on the <ir.rule>. Task-3693072 Forward-Port-Of: odoo/odoo#159126 Forward-Port-Of: odoo/odoo#156659
Currently, an analytic account is created when confirming a quotation for a product created as follow: 1. Enable `Can be Expensed` 2. Select `At cost` for Re-invoice expenses 3. Disable `Can be expensed` Steps to reproduce: ------------------- * Install **sale_management** and **hr_expense** * Go to **Settings** * Under `Customer Invoices`, enable `Intrastat` -> Save * Under `Analytics`, enable `Analytic Accounting` * Go to **Sales** * Create 3 products * Product 1: Default *
Original PR description
Currently, an analytic account is created when confirming a quotation for a product created as follow: 1. Enable `Can be Expensed` 2. Select `At cost` for Re-invoice expenses 3. Disable `Can be…
Currently, an analytic account is created when confirming a quotation for a product created as follow:
1. Enable `Can be Expensed`
2. Select `At cost` for Re-invoice expenses
3. Disable `Can be expensed`
Steps to reproduce:
-------------------
* Install **sale_management** and **hr_expense**
* Go to **Settings**
* Under `Customer Invoices`, enable `Intrastat` -> Save
* Under `Analytics`, enable `Analytic Accounting`
* Go to **Sales**
* Create 3 products
* Product 1: Default
* Product 2:
* Enable `Can be Expensed`
* Select `At cost` for Re-invoice expenses
* Product 3:
* Enable `Can be Expensed`
* Select `At cost` for Re-invoice expenses
* Disable `Can be expensed`
* For each product, repeat:
* Create a quotation, select a customer
* Add the product
* Confirm
* Select tab `Other Info`
* Check the analytic account
**Observations:**
* Product 1: No analytic account created
* Product 2: Analytic account created
* Product 3: Analytic account created
Why the fix:
------------
The creation of the analytic account depends on the value of `expense_policy`. When the value is `no`, no analytic account is created. Whereas when the value is `cost`, an analytic account is created.
https://github.com/odoo/odoo/blob/57ad9c05014ca0219d7892c1ff8a2e949fab3c49/addons/sale/models/sale_order.py#L853-L856
In this workflow, `expense_policy` is visible only when `Can be expensed` is enabled. If you select an `expense_policy` then disable `Can be expensed`, the value for the `expense_policy` stays as previously selected.
https://github.com/odoo/odoo/blob/3e320ffe0ff4d1c6bb7d0314f36dd13ad1cf23f4/addons/sale_expense/models/product_template.py#L33-L41
opw-3706305
Forward-Port-Of: odoo/odoo#159084
Forward-Port-Of: odoo/odoo#154153**Current behavior before PR:** When attempting to copy a button that is a direct child of a div tag, the div was unintentionally copied along with the button, leading to additional space upon pasting, along with the background color. **Desired behavior after PR is merged:** Now, only the button will be copied and pasted. task-3764652 Forward-Port-Of: odoo/odoo#158975 Forward-Port-Of: odoo/odoo#155212
Original PR description
**Current behavior before PR:** When attempting to copy a button that is a direct child of a div tag, the div was unintentionally copied along with the button, leading to additional space upon pasting, along with the background color. **Desired behavior after PR is merged:** Now, only the button will be copied and pasted. task-3764652 Forward-Port-Of: odoo/odoo#158975 Forward-Port-Of: odoo/odoo#155212
Refactored the restrict_parnter_id check in the stock_account module to make it more flexible for future updates.The The purpose of this refactoring is to prepare for a custom module that will value inventory based on specific ownership. Related: https://github.com/OCA/stock-logistics-workflow/pull/1548 @qrtl QT4334 Forward-Port-Of: odoo/odoo#158343
Original PR description
Refactored the restrict_parnter_id check in the stock_account module to make it more flexible for future updates.The The purpose of this refactoring is to prepare for a custom module that will value inventory based on specific ownership. Related: https://github.com/OCA/stock-logistics-workflow/pull/1548 @qrtl QT4334 Forward-Port-Of: odoo/odoo#158343
Before this PR, a race condition occurred when posting a message: if the bus notification was received before the result of the message post RPC, the unread counter was set to the number of messages in the channel. This occurs because the `discuss.channel.member/seen` notification is processed before the `discuss.channel/new_message` one so the message is not yet inserted in `thread.messages`. Steps to reproduce the issue: - Go to discuss as admin - Open a chat with demo - Set network t
Original PR description
Before this PR, a race condition occurred when posting a message: if the bus notification was received before the result of the message post RPC, the unread counter was set to the number of messages in the channel. This occurs because the `discuss.channel.member/seen` notification is processed before the `discuss.channel/new_message` one so the message is not yet inserted in `thread.messages`. Steps to reproduce the issue: - Go to discuss as admin - Open a chat with demo - Set network throttling to "fast 3g" - Send a message in the chat - The unread counter is now set to "1" which is incorrect Forward-Port-Of: odoo/odoo#158087
Before this commit, when creating a many2one field from an xml, with an impossible combination "`required=True` - `on_delete='set null'`", the column was not created in the database without any notice to the user. This commit adds a constraint checking that any attempt to create a field with this configuration would raise a ValidationError. This constraint replaces the previous onchange method. Forward-Port-Of: odoo/odoo#158778
Original PR description
Before this commit, when creating a many2one field from an xml, with an impossible combination "`required=True` - `on_delete='set null'`", the column was not created in the database without any notice to the user. This commit adds a constraint checking that any attempt to create a field with this configuration would raise a ValidationError. This constraint replaces the previous onchange method. Forward-Port-Of: odoo/odoo#158778
**Current behavior:** In the jobs/ directory on the website, if a position has a location set in its configuration, the 'Location' label will display the name of the company rather than the city where it is located. **Expected behavior:** The city will be displayed under the 'Location' label. **Steps to reproduce:** 1. In the Recruitment app, give a job a location value 2. On the website, go to the jobs/ directory and navigate to the position from step 1 3. Click 'Apply Now!' and
Original PR description
**Current behavior:** In the jobs/ directory on the website, if a position has a location set in its configuration, the 'Location' label will display the name of the company rather than the city where it is located. **Expected behavior:** The city will be displayed under the 'Location' label. **Steps to reproduce:** 1. In the Recruitment app, give a job a location value 2. On the website, go to the jobs/ directory and navigate to the position from step 1 3. Click 'Apply Now!' and look at the location label on the right side of the page **Cause of the issue:** This field was missing the "contact" widget type in its t-options. **Fix:** Add the widget type and additionally display "Remote" for the location when there is no location set. opw-3761348 Forward-Port-Of: odoo/odoo#159074 Forward-Port-Of: odoo/odoo#156239
1 change
Resolved issues and error corrections
This update fixes a minor issue where certain elements within the Point of Sale (POS) session, including numpad buttons and client editor fields, were not displaying translated text. This ensures a consistent and localized experience for users interacting with the POS system, regardless of their language settings. The fix addresses a reported problem (opw-3783252, opw-3756593) and improves usability.
Original PR description
Issue ----- In a POS session, some buttons of the numpad and some fields in the client editor form are not translated. **opw-3783252 opw-3756593** Forward-Port-Of: odoo/odoo#157509
21 changes
New functionality added to Odoo
This adds a payment step to appointment booking so customers can be required to pay before their slot is fully confirmed. It helps businesses reduce unpaid bookings, manage appointment capacity more accurately, and send confirmations only after payment when required.
Original PR description
WIP Task-3079302
Enhancements to existing features
This update adds safeguards to discourage point-of-sale modules from directly using the shared POS state inside business data models. It helps reduce future maintenance risk and supports a cleaner, more reliable POS architecture without changing day-to-day user workflows.
Original PR description
*: all pos related modules The pos_store is a global variable that is used to store the current state of the POS. Before we were able to access it from the models directly, but this is not a good practice. For the moment a patch is added to keep the use of it in differents places, but in the future we should remove it from the models and use the pos_store only in the components. A eslint rule is added to prevent the use of pos_store in the models.
A new debug report helps teams understand why payment methods or providers are available or unavailable in specific payment forms. This improves troubleshooting for payment setup across subscriptions, appointments, SEPA direct debit, and website upsell flows while also standardizing related naming internally.
Original PR description
Since 17.0 payment methods were introduced to the user and it became more difficult to debug them in the payment form. For that reason with this commit we added the availability report in payment form that can be displayed in debug mode. The report includes information about compatibility of each payment method and each provider for the given payment context and the reason if it is incompatible. task-2882668 The cleanup is included in this PR as well. - Unified variable name See related PR: - https://github.com/odoo/odoo/pull/151040 - https://github.com/odoo/upgrade/pull/5858
Resolved issues and error corrections
Payroll structure types now have a consistent ordering, preventing the system from picking different records in identical situations. This improves reliability in payroll processing and avoids unexpected behavior caused by database ordering differences.
Original PR description
This fixes an issue that was revealed by the change in the record updates. The root cause is the fact that the order on model `hr.payroll.structure.type` is nondeterministic. Because the order of row updates is slightly different, `search()` with `limit=1` was returning a different record!
Spreadsheet formula suggestions now use the updated names for pivot functions. This prevents confusion when users type formulas and helps them select the correct pivot-related options.
Original PR description
Pivot functions have been recently renamed by 8f797f954 The auto-complete code was not updated accordingly (it was done in //) Task: 3823297
Code cleanup and technical improvements
Point-of-sale related test files were renamed and reorganized to follow a consistent structure across modules. This internal cleanup makes tests easier for teams to find and maintain, without changing customer-facing behavior.
Original PR description
*: all pos-related modules 1. Use snake_case on file names similar to how we name other files. 2. Tour files are suffixed with `_tour`. 3. Helper files are moved to `/tours/utils` and are suffixed with `_util`. tasks id : 3794884 https://github.com/odoo/odoo/pull/157180
Miscellaneous changes
The issue: In the accounting report, in the process of creating the temporary table analytic_temp_account_move_line, that should match the account_move_line schema, we opt for NULL values, casting them to match the column type to match account_move_line table columns type. Now, if you have a field of any type that is not standard in PSQL (like HTML) in the account.move.line model, the query will try to cast a NULL to this type (which is HTML in this case), therefore will throw a traceback
Original PR description
The issue: In the accounting report, in the process of creating the temporary table analytic_temp_account_move_line, that should match the account_move_line schema, we opt for NULL values, casting them to match the column type to match account_move_line table columns type. Now, if you have a field of any type that is not standard in PSQL (like HTML) in the account.move.line model, the query will try to cast a NULL to this type (which is HTML in this case), therefore will throw a traceback The fix: Instead of casting NULL to Odoo type, which is in some cases not a valid type for PSQL (Like HTML type), this PR aims to cast any of these fields to the appropriate PSQL type opw-3782724 Forward-Port-Of: odoo/enterprise#58617
Before this commit, if setting a condition on a column in studio, it was on the 'column_invisible'. In result, the column was not invisible because it was conditional on the lines. So you cannot make the column dissapear on some line and not other in a list view. After this commit, the property selected when setting a condition is 'invisible'. Like that the cell is invisible and not the column. opw-ticket: 3667210 Forward-Port-Of: odoo/enterprise#58283 Forward-Port-Of: odoo/enterprise#545
Original PR description
Before this commit, if setting a condition on a column in studio, it was on the 'column_invisible'. In result, the column was not invisible because it was conditional on the lines. So you cannot make the column dissapear on some line and not other in a list view. After this commit, the property selected when setting a condition is 'invisible'. Like that the cell is invisible and not the column. opw-ticket: 3667210 Forward-Port-Of: odoo/enterprise#58283 Forward-Port-Of: odoo/enterprise#54527
Before this commit, when duplicating a read-only template a traceback was being triggered since we were passing a single template to the copy method. After this commit, we call the copy function passing a batch of a single element, which will return a list of templates containing a single template. After that, we call the action to open this copied template. task-3790206 Forward-Port-Of: odoo/enterprise#59198
Original PR description
Before this commit, when duplicating a read-only template a traceback was being triggered since we were passing a single template to the copy method. After this commit, we call the copy function passing a batch of a single element, which will return a list of templates containing a single template. After that, we call the action to open this copied template. task-3790206 Forward-Port-Of: odoo/enterprise#59198
**Steps to reproduce the bug:** - Create a storable product P1 with BoM: - Workorder: OP1 workcenter: Assembly 1 - Create a MO with P1 and confirm it - Go to the shop floor: - Select “Assembly 1” and “Drill 1” - Go to assembly 1 > select the workorder OP1 - on the right side of the footer in as ": (option)" button, which opens a pop-up window with additional options for the work order - click on “Move to workcenter” - Select “Drill 1” **Problem:** Change is
Original PR description
**Steps to reproduce the bug:** - Create a storable product P1 with BoM: - Workorder: OP1 workcenter: Assembly 1 - Create a MO with P1 and confirm it - Go to the shop floor: - Select “Assembly 1” and…
**Steps to reproduce the bug:**
- Create a storable product P1 with BoM:
- Workorder: OP1 workcenter: Assembly 1
- Create a MO with P1 and confirm it
- Go to the shop floor:
- Select “Assembly 1” and “Drill 1”
- Go to assembly 1 > select the workorder OP1
- on the right side of the footer in as ": (option)" button, which opens a pop-up window with additional options for the work order
- click on “Move to workcenter”
- Select “Drill 1”
**Problem:**
Change is applied in the frontend view (JS side) but not in the backend. If you refresh the page, the change will be lost. This is due to this commit:
https://github.com/odoo/odoo/commit/6bd2c1fdfb5722b1f2d4fc2684f20ed067b93b7d The purpose of this commit is to no longer save the record of an x2many when an autosave field is applied to an update
**Solution:**
Revert the changes made in this commit:
https://github.com/odoo/enterprise/commit/518dcd935094e30c8a39982be9b3ddb161bd03cd#diff-7df14ba8355f342f6f776e8ea293eb97ab75660c0f57245f5941e8d1da9a49bbR42-R45
opw-3816964
Forward-Port-Of: odoo/enterprise#59184
Forward-Port-Of: odoo/enterprise#59120Before this commit on the sign request when leaving the validity field empty and clicking on a different place, the following error occurs: """ .... if self.validity < fields.Date.today(): TypeError: '<' not supported between instances of 'bool' and 'datetime.date' """ This commit aims to fix this issue by adding an additional condition before comparing the validity. Task: 3750526 Forward-Port-Of: odoo/enterprise#57196
Original PR description
Before this commit on the sign request when leaving the validity field empty and clicking on a different place, the following error occurs: """ .... if self.validity < fields.Date.today(): TypeError: '<' not supported between instances of 'bool' and 'datetime.date' """ This commit aims to fix this issue by adding an additional condition before comparing the validity. Task: 3750526 Forward-Port-Of: odoo/enterprise#57196
Importing large winbooks zip files can sometimes lead to a MemoryError. For instance, importing 360 000 account.moves in one go requires 3.1Gb of allocated memory, too much for a 2gb worker. This commit uses the fact that the get_dbfrecords function returns an iterator. The result_iterator yields all the items that pass the BOOKYEAR and DOCNUMBER condition. Also, yielding a frozendict allows to remove duplicate at the time of building the grouped defaultdict instead of when consuming the dbfr
Original PR description
Importing large winbooks zip files can sometimes lead to a MemoryError. For instance, importing 360 000 account.moves in one go requires 3.1Gb of allocated memory, too much for a 2gb worker. This…
Importing large winbooks zip files can sometimes lead to a MemoryError. For instance, importing 360 000 account.moves in one go requires 3.1Gb of allocated memory, too much for a 2gb worker. This commit uses the fact that the get_dbfrecords function returns an iterator. The result_iterator yields all the items that pass the BOOKYEAR and DOCNUMBER condition. Also, yielding a frozendict allows to remove duplicate at the time of building the grouped defaultdict instead of when consuming the dbfrecords iterator. That's because frozendict are hashable. By removing the intermediate recs and result local variables in `_import_move`, the memory peak drops to 1.6Gb, allowing to import the winbooks export on a 2gb worker. Add a more user-friendly error when there is no sub_zips in the main zip container. This can happen if the customer extracts the winbooks archive and tries to import the sub_zip directly. #### Benchmark Customer v17 database importing a 102Mb zip winbooks export containing 357825 moves. ##### Memray stats before PR, peak at 3.1Gb  ##### Memray stats after PR, peak at 1.6Gb  Forward-Port-Of: odoo/enterprise#56059
Since [1], it's now possible for a client action to use the resId and update the resId on the URL as a form view will do. To do this two props are given to the client action: resId and updateResId. This commit adds the missing props to existing client actions that were forgotten by the initial commit. [1] https://github.com/odoo/odoo/commit/3ad4fd65387f60b524e5f786556963ead8ae9dfe Forward-Port-Of: odoo/enterprise#59352
Original PR description
Since [1], it's now possible for a client action to use the resId and update the resId on the URL as a form view will do. To do this two props are given to the client action: resId and updateResId. This commit adds the missing props to existing client actions that were forgotten by the initial commit. [1] https://github.com/odoo/odoo/commit/3ad4fd65387f60b524e5f786556963ead8ae9dfe Forward-Port-Of: odoo/enterprise#59352
Steps to reproduce: - Set up DHL shipping - Create Sale order, add dhl shipping and validate the delivery Bug: the shipper and reciver referrence are empty on the created comercial invoice opw-3775347 Forward-Port-Of: odoo/enterprise#59318 Forward-Port-Of: odoo/enterprise#59208
Original PR description
Steps to reproduce: - Set up DHL shipping - Create Sale order, add dhl shipping and validate the delivery Bug: the shipper and reciver referrence are empty on the created comercial invoice opw-3775347 Forward-Port-Of: odoo/enterprise#59318 Forward-Port-Of: odoo/enterprise#59208
Before: Spreadsheet can be renamed to blank spaces. After: If a spreadsheet is renamed to blank spaces, the placeholder value will auto reset back to original name or default untitled name. Task: 3559704 Forward-Port-Of: odoo/enterprise#59145 Forward-Port-Of: odoo/enterprise#51550
Original PR description
Before: Spreadsheet can be renamed to blank spaces. After: If a spreadsheet is renamed to blank spaces, the placeholder value will auto reset back to original name or default untitled name. Task: 3559704 Forward-Port-Of: odoo/enterprise#59145 Forward-Port-Of: odoo/enterprise#51550
Before: when a CFDI wasn't created successfully, the retry button wasn't shown to force the user to go back to the send & print button to generate the invoice PDF. Now: the retry button is shown and the generation of the PDF is done by manually triggering the send and print process. task-3687266 Forward-Port-Of: odoo/enterprise#54835
Original PR description
Before: when a CFDI wasn't created successfully, the retry button wasn't shown to force the user to go back to the send & print button to generate the invoice PDF. Now: the retry button is shown and the generation of the PDF is done by manually triggering the send and print process. task-3687266 Forward-Port-Of: odoo/enterprise#54835
When having an asset beginning at the beginning of a period and having one period, the board values are wrongly computed although the depreciation move lines are good. Steps: - Create an asset with acquisition date set at the first day of a month - Set the period to 1 month - Set the same account as fixed asset account and depreciation account - Compute board and show depreciation moves tab -> Depreciation value, remaining value and cumulated depreciation are wrong The reason is that we en
Original PR description
When having an asset beginning at the beginning of a period and having one period, the board values are wrongly computed although the depreciation move lines are good. Steps: - Create an asset with acquisition date set at the first day of a month - Set the period to 1 month - Set the same account as fixed asset account and depreciation account - Compute board and show depreciation moves tab -> Depreciation value, remaining value and cumulated depreciation are wrong The reason is that we enter in a condition meant for set the value of closing entry when needed, which is not the case here. As there is no way, at the moment we enter this condition, to check if the asset is ment to be closed (state is still set to 'open'), the solution is to add a context key to achieve that. opw-3750254 Forward-Port-Of: odoo/enterprise#58595
# Issue: Data Cleaning App is slow. # Analyze: - There is no check on model duplication to generate subqueries. - For each domain search, the queries have subqueries joined with "UNION" which are slow and can't be optimized by the Planner. # Fix: - Remove duplicated models which generate the same condition. - Avoid subqueries and make one big query with each one of the subqueries. # Benchmark: | # Input data | Before PR | After PR | |:-------------:|:----------:|:---------:| |
Original PR description
# Issue: Data Cleaning App is slow. # Analyze: - There is no check on model duplication to generate subqueries. - For each domain search, the queries have subqueries joined with "UNION" which are…
# Issue: Data Cleaning App is slow. # Analyze: - There is no check on model duplication to generate subqueries. - For each domain search, the queries have subqueries joined with "UNION" which are slow and can't be optimized by the Planner. # Fix: - Remove duplicated models which generate the same condition. - Avoid subqueries and make one big query with each one of the subqueries. # Benchmark: | # Input data | Before PR | After PR | |:-------------:|:----------:|:---------:| | 5144 dmr (3 models) | 1,91 s | 0,31 s | | 974 931 dmr (3 models) | 7:09 min | 33,86 s ( Hot cache : 5,62s) | | 8 804 632 dmr (6 models) | Crash after 5:30 min | 1:19 min | # Note: - I tried it with the biggest database I could access, I didn't crash but on big databases with a lot of related model, there would be a bunch of LEFT JOIN and that could have a Memory Limit. (In any case it wouldn't work with current implementation) - The index could help on the planner, but it is not required (while it can't hurt to have an index on a Many2One). # Related task: opw-3696044 Speedscope in attachment in the task Forward-Port-Of: odoo/enterprise#56536
Steps to reproduce: - Set up DHL shipping - Create Sale order with a currency different than the company one - Add dhl shipping and validate the delivery Bug: the created comercial invoice is in the company currency instead of the SO Fix: apply same logic as 15.0 set currency to SO and fallback to the company currency if no SO is linked to the delivery opw-3775347 Forward-Port-Of: odoo/enterprise#59177
Original PR description
Steps to reproduce: - Set up DHL shipping - Create Sale order with a currency different than the company one - Add dhl shipping and validate the delivery Bug: the created comercial invoice is in the company currency instead of the SO Fix: apply same logic as 15.0 set currency to SO and fallback to the company currency if no SO is linked to the delivery opw-3775347 Forward-Port-Of: odoo/enterprise#59177
Currently, when the user and the target both are in multiple companies, the profile button cannot be displayed correctly. Since the employee_id uses `('company_id', '=', self.env.company.id)` rather than `in`. In community branch we fixed it by checking employee_ids directly and if it is found, the profile button will be displayed correctly. In order to accommodate that change, we needed to filter out employee_ids and add employee_id in fields for patchAvatarCardResourcePopover, as resourc
Original PR description
Currently, when the user and the target both are in multiple companies, the profile button cannot be displayed correctly. Since the employee_id uses `('company_id', '=', self.env.company.id)` rather than `in`.
In community branch we fixed it by checking employee_ids directly and if it is found, the profile button will be displayed correctly.
In order to accommodate that change, we needed to filter out employee_ids and add employee_id in fields for patchAvatarCardResourcePopover, as resource.resource has no field employee_ids.
Forward-Port-Of: odoo/enterprise#59058
Forward-Port-Of: odoo/enterprise#58964Part 1: https://github.com/odoo/odoo/pull/152930 Part 2: https://github.com/odoo/odoo/pull/153018 Part 3: https://github.com/odoo/odoo/pull/153023 Part 4: https://github.com/odoo/odoo/pull/153203 Part 5: https://github.com/odoo/odoo/pull/153425 Part 6: https://github.com/odoo/odoo/pull/153700 Part 7: https://github.com/odoo/odoo/pull/154054 Part 8: https://github.com/odoo/odoo/pull/154579 Part 9: https://github.com/odoo/odoo/pull/155073 Part 10: https://github.com/odoo/odoo/pull/155639
Original PR description
Part 1: https://github.com/odoo/odoo/pull/152930 Part 2: https://github.com/odoo/odoo/pull/153018 Part 3: https://github.com/odoo/odoo/pull/153023 Part 4: https://github.com/odoo/odoo/pull/153203…
Part 1: https://github.com/odoo/odoo/pull/152930 Part 2: https://github.com/odoo/odoo/pull/153018 Part 3: https://github.com/odoo/odoo/pull/153023 Part 4: https://github.com/odoo/odoo/pull/153203 Part 5: https://github.com/odoo/odoo/pull/153425 Part 6: https://github.com/odoo/odoo/pull/153700 Part 7: https://github.com/odoo/odoo/pull/154054 Part 8: https://github.com/odoo/odoo/pull/154579 Part 9: https://github.com/odoo/odoo/pull/155073 Part 10: https://github.com/odoo/odoo/pull/155639 Part 11: https://github.com/odoo/odoo/pull/156255 / https://github.com/odoo/enterprise/pull/58135 Part 12: https://github.com/odoo/odoo/pull/156869 Community: https://github.com/odoo/odoo/pull/158384 This pull requests brings various improvements and fixes to Hoot and the Odoo unit test ecosystem. See the different commit messages for more details. Note: these changes are made in stable to avoid having to support multiple versions of the HOOT API. As such, these changes are intended to be strictly limited to unit tests as to not put the rest of the code base at risk. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/enterprise#59019
45 changes
Enhancements to existing features
This update adjusts the private car reimbursement rates in the Belgian payroll system to comply with 2024 regulations. The changes ensure that employee car allowances are calculated correctly according to the latest Belgian tax and labor law requirements, affecting how payslips are generated for employees using private vehicles for business purposes.
Original PR description
https://www2.partena-professional.be/LegalPortal/servlet/servlet.FileDownload?file=00P3X00002H45q2UAB
This update enhances the UAE payroll module by adding the necessary salary calculation inputs and rules required for accurate payroll processing in the United Arab Emirates. The changes ensure that the payroll system now has complete support for UAE-specific salary calculations and compliance requirements.
Original PR description
Change adds inputs and rules used for calculating salary in UAE. task-3634461 Forward-Port-Of: odoo/enterprise#53553
This update adds a loading spinner and disables the sign button while an order signature request is being processed. This prevents users from accidentally clicking the button multiple times, which was causing errors and confusion. The improvement makes the signing process clearer and more reliable for customers.
Original PR description
opw-3709064 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The portal icon size is now restricted to a standard 64x64 pixel dimension. This ensures consistency across the platform and eliminates the need for manual icon resizing, making the portal experience more uniform and reducing administrative overhead.
Original PR description
-Sometime we may receive a portal icon that can be a little big or a little small in size, then in order to make it perfectly fit to client portal we will have to edit the icon to 64x64, invoice, sale, project app all have the same 64x64 portal icon. -Therefore we should restrict it to 64x64 to ensure no further action is needed Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The stock accounting module has been improved to make it easier to customize how inventory ownership is tracked. This refactoring simplifies the code structure, allowing future enhancements for valuing inventory based on specific ownership without requiring extensive code modifications. This change prepares the system for more flexible inventory management capabilities.
Original PR description
Refactored the restrict_parnter_id check in the stock_account module to make it more flexible for future updates.The The purpose of this refactoring is to prepare for a custom module that will value inventory based on specific ownership. Related: https://github.com/OCA/stock-logistics-workflow/pull/1548 @qrtl QT4334 Forward-Port-Of: odoo/odoo#158343
Resolved issues and error corrections
This fix prevents the system from crashing when approval rules reference models that no longer exist (such as deleted, renamed, or custom models). The system now gracefully skips these non-existent models instead of throwing an error during startup, ensuring smoother upgrades and system stability.
Original PR description
If a `studio.approval.rule` refers to a non-existing model (e.g. the model was removed, or renamed, or it's a custom model that is not present during an upgrade), then while attempting to patch the…
If a `studio.approval.rule` refers to a non-existing model (e.g. the model was removed, or renamed, or it's a custom model that is not present during an upgrade), then while attempting to patch the rule's method the registry will [return](https://github.com/odoo/enterprise/blob/961f67d776a8ec1d9293ed599f284807930496d5/web_studio/models/studio_approval.py#L200) a `None` model, which then causes an AttributeError.
We add a check for the Model's existence, so that any None models are skipped. This follows the approach in [base_automation](https://github.com/odoo/odoo/blob/d11ece23e97189f38040254917a3517e21386e47/addons/base_automation/models/base_automation.py#L847-L857), which was the technical inspiration for the [commit](https://github.com/odoo/enterprise/commit/3db107ae481a8da85aa356c729bae5fc246e655b) that implemented the approval rule logic.
Ticket: [3754939](https://www.odoo.com/web#id=3754939&cids=1&menu_id=4720&action=333&active_id=70&model=project.task&view_type=form), [3777251](https://www.odoo.com/web#id=3754939&cids=1&menu_id=4720&action=333&active_id=70&model=project.task&view_type=form)
```
Traceback (most recent call last):
File "/home/odoo/src/odoo/17.0/odoo/service/server.py", line 1302, in preload_registries
registry = Registry.new(dbname, update_module=update_module)
File "<decorator-gen-16>", line 2, in new
File "/home/odoo/src/odoo/17.0/odoo/tools/func.py", line 87, in locked
return func(inst, *args, **kwargs)
File "/home/odoo/src/odoo/17.0/odoo/modules/registry.py", line 113, in new
odoo.modules.load_modules(registry, force_demo, status, update_module)
File "/home/odoo/src/odoo/17.0/odoo/modules/loading.py", line 606, in load_modules
model._register_hook()
File "/home/odoo/src/enterprise/17.0/web_studio/models/studio_approval.py", line 203, in _register_hook
_patch(Model, approval.method, approval_method)
File "/home/odoo/src/enterprise/17.0/web_studio/models/studio_approval.py", line 132, in _patch
ModelClass = model.env.registry[model._name]
AttributeError: 'NoneType' object has no attribute 'env'
```This update fixes the Send & Print feature in the electronic invoicing systems for Brazil and Mexico. The implementation has been cleaned up to ensure the feature works correctly when users want to send and print documents simultaneously.
Original PR description
Clean the implementation.
This fix corrects an incorrect account mapping in the Swiss payroll module where salary advance transactions were being linked to the wrong account code. The account code 5003 (Salary Advance) was incorrectly pointing to account 5004 (Holidays payment after departure). This correction ensures that salary advance payments are now recorded in the proper account, improving financial accuracy and reporting.
Original PR description
The account code 5003 is used for the salary advance account but in hr.salary.rule the account linked to it is 5004 Holidays payment after departure. see [here](https://github.com/odoo/enterprise/blob/17.0/l10n_ch_hr_payroll_account/models/account_chart_template.py#L15). But that should be Salary Advance. Although I am not very sure about this, I saw the code and it seems to be suspicious. Before fix:-  After fix:- 
This update corrects visibility rules for fields in Mexico's Delivery Guide (Carta Porte) version 3.0. Specific fields now display only when appropriate: material type shows for external trade, tax registration appears for non-Mexican customers, and customs fields display regardless of shipment status. These fixes ensure the delivery guide generates correctly for Mexican compliance requirements.
Original PR description
There were a few issues with the new version 3.0 of the Delivery Guide (Carta Porte): - TipoMateria should only be visible when it's an external trade. - NumRegIdTrib should only be visible when the customer's country is not MX. - Visibility of customs related fields (that were added in version 3.0) should not depend on the state of the picking. task-3755473 Forward-Port-Of: odoo/enterprise#57822
This fix resolves an error in accounting reports that occurred when creating temporary tables with non-standard database field types (like HTML fields). The system now properly converts Odoo field types to compatible database types instead of attempting invalid conversions, preventing report generation failures.
Original PR description
The issue: In the accounting report, in the process of creating the temporary table analytic_temp_account_move_line, that should match the account_move_line schema, we opt for NULL values, casting them to match the column type to match account_move_line table columns type. Now, if you have a field of any type that is not standard in PSQL (like HTML) in the account.move.line model, the query will try to cast a NULL to this type (which is HTML in this case), therefore will throw a traceback The fix: Instead of casting NULL to Odoo type, which is in some cases not a valid type for PSQL (Like HTML type), this PR aims to cast any of these fields to the appropriate PSQL type opw-3782724 Forward-Port-Of: odoo/enterprise#58617
Chilean customers using the ecommerce checkout were unable to complete purchases when selecting the 'Ticket' payment option with automatic invoicing enabled. The system was incorrectly requiring them to complete an incomplete anonymous billing address they didn't have permission to edit. This fix ensures the anonymous address is treated as complete, allowing the checkout flow to proceed smoothly.
Original PR description
Chilean ecommerce checkout flow was consistently breaking when automatic invoice was enabled (Sale settings), for customers choosing the 'Ticket' option (not the 'Invoice' one). Indeed, choosing the 'Ticket' options sets a generic 'Anonymous' customer as billing address, but since this address is incomplete, the customer is redirected to the page to complete it, even though they don't have the rights to update that address since it's not theirs. This commit makes sure to consider this 'anonymous' billing address as being always complete, even if some fields are empty. opw-3792844
This fix removes a duplicate variable that was accidentally introduced in the Dutch localization tax reporting module. The change cleans up test code to ensure the module functions correctly without redundant data.
Original PR description
During this commit: https://github.com/odoo/enterprise/commit/02252c3af7637835e34d0c19a609e1aa05b5a653#diff-fcb2837955e2fcf5fb3885f86c0f12f8facd7cd24d73e1f151957c33db381f9e A duplicate variable was introduced. This commit will remove that. no task-id
This fix corrects an incorrect visibility setting for the phone field in the WhatsApp message composer. The issue occurred during a code merge and has been resolved to ensure the phone field displays properly when composing WhatsApp messages.
Original PR description
Wrong conflict resolution when forward porting odoo/enterprise@7ff6e2b04110d1e3c046388927409ec46d39800e Task-3778173
This fix resolves an error that occurred in the document signing feature when users left the validity field empty. Previously, the system would crash with a technical error when trying to validate the date. Now the system properly handles empty validity fields, allowing users to proceed without interruption.
Original PR description
Before this commit on the sign request when leaving the validity field empty and clicking on a different place, the following error occurs: """ .... if self.validity < fields.Date.today(): TypeError: '<' not supported between instances of 'bool' and 'datetime.date' """ This commit aims to fix this issue by adding an additional condition before comparing the validity. Task: 3750526 Forward-Port-Of: odoo/enterprise#57196
This fix corrects a bug where the timer filter was displaying incorrect records when a task and ticket shared the same ID. Previously, when filtering by "User Timer is set," tickets without an active timer would incorrectly appear in the results. The fix ensures the search properly distinguishes between different record types by including the model type in the filter condition.
Original PR description
When a task and a ticket share the same ID, the _search_user_timer_id method will not work and provide the wrong result when using User Timer as the filter. Steps to reproduce: Having a task and a ticket with the same ID. Start the timer in the task. Go to the ticket and filter by "User Timer is set" There will be a ticket without a timer running but still showing in the search result. Cause The search method did not take into consideration of model. Solution Add model as a condition when searching timer records
This fix resolves errors that occurred in the sales subscription dashboard when it was used without demo data. The dashboard formulas have been updated to gracefully handle missing data by displaying empty cells instead of errors, ensuring a better user experience.
Original PR description
## Description: Before this fix, errors occurred in certain sections of the sales subscription dashboard when attempting to load it without demo data. This PR resolves the problem by incorporating IFERROR into the formulas to leave them empty in case of errors. Task ID: [3754211](https://www.odoo.com/web#id=3754211&cids=2&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form) Forward-Port-Of: odoo/enterprise#58155
This fix prevents the system from sending reminder notifications for signature requests that have been archived. Previously, archived requests were incorrectly triggering reminders through automated processes, which could confuse users. Now the system properly skips archived requests when sending reminders.
Original PR description
Before this commit, some archived sign.requests were triggering reminders by the cron when they shouldn't, because they weren't active anymore. After this commit, archived sign.requests no longer trigger reminders by the cron, they are skipped in the SQL query. task-3806013 Forward-Port-Of: odoo/enterprise#58649
This update prevents users from reverting tax closing entries to draft status if newer closing entries have already been posted. This ensures closing entries are reset in proper chronological order, which is essential for accurate carryover calculations and financial record integrity. The change also fixes inconsistent behavior in the Tax Report's Closing Entry button.
Original PR description
Prevents the user to reset to draft a tax closing entry if subsequent closing entries are already posted. This way, the user is forced to reset to draft progressively back in time the closing entries. Accounting wise, this case should not happen. It is by the way prevented by the irreversible_lock_date module (which can be however uninstalled). This mechanism solves an issue with carryovers that need to be progressively recomputed when resetting to draft a closing entry. Another issue has also been fixed. The 'Closing Entry' button in the Tax Report has inconsistent behavior when the closing entry is already posted and then reset to draft. This issue was solved in 17 in this commit: https://github.com/odoo/enterprise/commit/49f664db942f3b7f5d343ac7a42608839b5595bf. It is backported in order to make the draft closing entry flow as smooth as possible. task-3520338 Forward-Port-Of: odoo/enterprise#58869 Forward-Port-Of: odoo/enterprise#52875
This fix prevents users from changing whether a product is set up for recurring invoicing once it has already been included in a confirmed sales order. Previously, while a warning was shown, the system would still allow the change, which could cause confusion. Now the field is locked to maintain consistency with existing customer orders.
Original PR description
Issue: ------ It is possible to change the recurrence of a product if it has already been sold (correct behaviour). The customer receives a warning, but the `recurring_invoice` field is still set to `True`, whereas it may have been set to `False` before the operation. Solution: --------- Prevent the `recurring_invoice` field from being changed if a confirmed sale order line contains this product, to avoid confusion. opw-3457160
This update reorganizes calendar styling code to fix layout problems that occurred when using modules like Planning or HR Payroll without the Calendar module installed. The change moves essential calendar styles to the core Web module and fixes the display of hatched events in Planning's Day and Week views, ensuring consistent appearance across all related features.
Original PR description
### Move common scss into web Prior to this PR, some of the main styles related to event elements in calendars were set in the `calendar` module. This created layout issues when we installed…
### Move common scss into web Prior to this PR, some of the main styles related to event elements in calendars were set in the `calendar` module. This created layout issues when we installed independent modules without installing `calendar` (eg. `planning` or `hr_payroll`). To fix that, this PR moves the necessary styles into `web` and manages duplicated styles in order to remove them. ### Adjust hatched events for planning Prior to this commit, the "hatched" event style in Planning wasn't displayed in Day and Week views. This commit adjusts the css selector to fix this issue. --- task-3617329 Part of task-3575827 --- | Before | After | |--------|--------| |  |  | |  |  | | Before | After | |--------|--------| |  |  | --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes the Send & Print feature across multiple invoice and document management modules including UBL/CII, Peppol, Spanish and Italian electronic invoicing, and Snailmail integration. The fix cleans up the implementation and ensures all modules properly support the Send & Print functionality for document delivery.
Original PR description
…ail_account: fix Send & Print only Clean the implementation + missing peppol, ubl and snailmail.
This fix corrects an issue where time off requests were incorrectly spanning 2 days instead of 1 when users were in timezones ahead of UTC (like UTC+08:00). The problem occurred because date calculations weren't properly accounting for the user's local timezone before converting to dates. Now the system correctly applies timezone conversion before processing request dates, ensuring users see accurate single-day requests.
Original PR description
Steps to reproduce: ------------------- - be in a UTC+08:00 (or more) timezone - go to Time Off dashboard - click on a day (to request a leave) Issue: ------ Default request dates are on 2 days instead of 1. Cause: ------ Default request dates are determined during an onchange. The datetimes (`default_date_from/to`) are set in the context in UTC calculated in relation to the client's timezone. Consequently, these datetimes can be set over several days. In the backend, we will use these datetimes and take only the day (because the `request_date_from/to` fields are of type date). Solution: --------- Put the values back into the client's timezone before they are truncated. opw-3789265
This update fixes the visual appearance of the import tool when using dark mode. The background colors were too dark and inconsistent with other parts of the system, making the interface less appealing. The changes adjust the background colors to look better in both light and dark modes while maintaining consistency across the application.
Original PR description
This commit adapts `base_import`'s background that was too dark compared to other modules. This was caused by the use of a `bg-white` class that is not very "dark-mode friendly" as it will display as…
This commit adapts `base_import`'s background that was too dark compared to other modules. This was caused by the use of a `bg-white` class that is not very "dark-mode friendly" as it will display as a pure black, which is not visually appealing and not wanted. This commit also adapts the background color of the sidebar to make it more consistent with other modules. We also add a `bg-view` class to the table, so it stands out more in light mode and stays the same in dark mode. task-3814508 | Before | After | |--------|--------| | <img width="1728" alt="Screenshot 2024-03-22 at 08 32 26" src="https://github.com/odoo/odoo/assets/110090660/85c0d0bf-19af-4a19-aa1b-cf990a6147d8"> | <img width="1728" alt="Screenshot 2024-03-22 at 08 34 08" src="https://github.com/odoo/odoo/assets/110090660/dfe7198a-c011-4ead-bf6f-cfba50db93a9"> | | <img width="1726" alt="Screenshot 2024-03-22 at 08 32 42" src="https://github.com/odoo/odoo/assets/110090660/ed5914c2-bf1c-44ee-baa6-58fb5f537d9a"> | <img width="1725" alt="Screenshot 2024-03-22 at 08 34 19" src="https://github.com/odoo/odoo/assets/110090660/fb80a723-d1d0-4d44-aded-d603385cce70"> | | <img width="1714" alt="Screenshot 2024-03-22 at 08 59 52" src="https://github.com/odoo/odoo/assets/110090660/98c543a0-05dd-4b71-b5bf-9d702f513fb4"> | <img width="1715" alt="Screenshot 2024-03-22 at 08 57 41" src="https://github.com/odoo/odoo/assets/110090660/4005b050-4a2a-4137-b6c0-47ecbdbe89a7"> | | <img width="1726" alt="Screenshot 2024-03-22 at 08 33 08" src="https://github.com/odoo/odoo/assets/110090660/fde063f8-48f5-4ae2-a5c1-b1973d94f0b3"> | <img width="1728" alt="Screenshot 2024-03-22 at 08 33 59" src="https://github.com/odoo/odoo/assets/110090660/b5875104-7d6f-4a36-8303-0cf7c14c113d"> | --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#158019
This fix resolves an issue that prevented users from selecting Algeria as their fiscal localization package after installing the Algerian localization module. The problem was caused by duplicate tax names in the configuration data, which violated a uniqueness requirement. By making these tax names unique, companies can now successfully set up their Algerian fiscal localization.
Original PR description
**Current behavior:** Trying to select the Algerian fiscal localization for a company after installing the respective module is impossible. **Expected behavior:** The localization package should be installable after the module has been installed. **Steps to reproduce:** 1. Install `l10n_dz` and create a new company without any fiscal localization 2. In the fresh company, select `Algeria` as the fiscal localization package, observe the error **Cause of the issue:** Two tax names in the module's tax data file have the same values for a field that should be unique. **Fix:** Change the values in the identical fields. opw-3787096 Forward-Port-Of: odoo/odoo#157198
This update fixes how the text editor handles empty heading elements when users press backspace. Previously, empty headings (H4-H6) wouldn't be properly removed, and headings with text would incorrectly convert to paragraphs when backspacing at the start. Now, empty headings are correctly deleted on backspace, providing a more intuitive editing experience.
Original PR description
Before this PR:
1. When an empty heading from H4 to H6 is the only element in the editable
area, the backspace key doesn't turn it into paragraphs.
2. When the cursor is at the start of a heading element with text content, and the
user hits the backspace key, the element gets converted into a paragraph.
After this PR:
All heading elements are removed on backspace if they're empty.
task-3456815
Forward-Port-Of: odoo/odoo#132778This fix resolves an issue where copying a button would also copy its parent container, resulting in unwanted extra space and background color when pasting. Now users can copy and paste buttons cleanly without the parent container being included.
Original PR description
**Current behavior before PR:** When attempting to copy a button that is a direct child of a div tag, the div was unintentionally copied along with the button, leading to additional space upon pasting, along with the background color. **Desired behavior after PR is merged:** Now, only the button will be copied and pasted. task-3764652 Forward-Port-Of: odoo/odoo#155212
This update fixes icons that were displaying incorrectly when using right-to-left languages like Arabic. Previously, icons in image galleries, carousels, and other interface elements weren't properly flipped for RTL layouts. The fix ensures all Odoo icons now display correctly regardless of language direction, improving the user experience for RTL language users.
Original PR description
Prior to this PR, `oi` icons were not adapted when RTL was defined in frontend. This is because RTL adaptations were defined in the backend bundle. This PR moves the RTL adaptations to be used wherever `oi` icons can be defined. task-3794966 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#157214
Fixed an issue where job locations were incorrectly displaying the company name instead of the city on the website's job application page. The fix ensures that when a job has a location set, the correct city name appears under the 'Location' label, and displays "Remote" when no location is specified. This improves the accuracy of job listings for candidates browsing open positions.
Original PR description
**Current behavior:** In the jobs/ directory on the website, if a position has a location set in its configuration, the 'Location' label will display the name of the company rather than the city where it is located. **Expected behavior:** The city will be displayed under the 'Location' label. **Steps to reproduce:** 1. In the Recruitment app, give a job a location value 2. On the website, go to the jobs/ directory and navigate to the position from step 1 3. Click 'Apply Now!' and look at the location label on the right side of the page **Cause of the issue:** This field was missing the "contact" widget type in its t-options. **Fix:** Add the widget type and additionally display "Remote" for the location when there is no location set. opw-3761348 Forward-Port-Of: odoo/odoo#159074 Forward-Port-Of: odoo/odoo#156239
This fix corrects an issue where imported XML bills were incorrectly using purchase order prices instead of the prices specified in the XML file. When a vendor bill in XML format is matched to a purchase order, the bill now correctly preserves the pricing from the XML document rather than overwriting it with the PO price.
Original PR description
**Steps to reproduce:** - Install Accounting and Purchase - Go to Purchase and create a PO: * Vendor: Vendor X * Product: Product X * Unit Price: 50.00 - Create an electronic bill in XML format with: * a reference to PO name * the same partner than the PO * the same line than the PO, except for the price - Go to "Accounting / Vendors / Bills" - Upload the XML bill **Issue:** The bill is generated and linked to the PO, but the price and subtotal on the bill line is the one coming from the PO instead of the one coming from the XML. Values coming from an imported XML should not be overridden by values found in matching PO. **Cause:** "timeout" parameter is wrongly passed as "prefer_purchase_line" parameter in a call to "_find_and_set_purchase_orders" method. opw-3707731 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#158015
Users were unable to access their own attachments when uploading files in course reviews, resulting in 404 errors. This fix ensures that access tokens are properly generated for user attachments, allowing them to view files they've uploaded regardless of their user status.
Original PR description
Bug === 1. login as demo user 2. add a review on a course and upload an attachment 3. click on the attachment link => You get a 404 error For some reason, we do not return the access token if the user is internal. The generation is not a heavy process, and might be needed depending on the <ir.rule>. Task-3693072 Forward-Port-Of: odoo/odoo#158922 Forward-Port-Of: odoo/odoo#156659
This fix resolves an issue where buttons marked to close dialogs were not working properly when placed in the footer of related record list windows. The system now correctly identifies and uses the dialog closing function, ensuring these buttons work as expected when users interact with related records.
Original PR description
Before this commit, if a button had the attribute special="close" on the footer of an x2many dialog, the dialog was not closed. This occurs because the view button hook searches the dialog close functions put in the environment by the dialog component, and in this case is another component that initialize the hook, and the function is not found. Now, the view button hook will use the dialog close function put in the environment by the dialog service.
This fix resolves an issue where Odoo's auto-reload feature was not working on Windows 11 when using the latest watchdog library. The problem occurred because the watchdog library changed how it handles file event properties, causing the auto-reload to fail silently. This update ensures developers can now properly use the --dev=reload mode to automatically restart Odoo whenever they modify Python files, improving development productivity.
Original PR description
Description of the issue/feature this PR addresses: the autoreload does not work after modified python file(s), dev reload mode has been eanbled when start odoo on windows 11. i found the reason is: when a file modified, watchdog event has the property 'dest_path' but content is empty Current behavior before PR: odoo started with --dev=reload, the log show watchdog is watching addon folders but when i modified a python file, the odoo app did not restart, the log has no output. 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#157829
Fixed an issue where mobile users couldn't save edited log notes because the keyboard shortcut (CTRL+ENTER) wasn't available and there was no save button. A new save button with a paper plane icon has been added to the message composer, making it easy for mobile users to save their edits just like they would send a new message.
Original PR description
Example of steps: - Open any record with a chatter - Log a note - Edit it - Try to save Actually it is impossible to save it, because we can not perform a CTRL+ENTER in mobile and there is no button This commit adds a button to save editing, using `fa-paper-plane` icon similarly to send button. opw-3784145
This fix corrects a bug where products that had expense settings enabled, then disabled, would still create analytic accounts when used in sales quotations. The issue occurred because the expense policy setting was retained even after disabling the "Can be Expensed" option. Now the system properly resets the expense policy when the expense feature is disabled, ensuring consistent behavior across all product configurations.
Original PR description
Currently, an analytic account is created when confirming a quotation for a product created as follow: 1. Enable `Can be Expensed` 2. Select `At cost` for Re-invoice expenses 3. Disable `Can be…
Currently, an analytic account is created when confirming a quotation for a product created as follow:
1. Enable `Can be Expensed`
2. Select `At cost` for Re-invoice expenses
3. Disable `Can be expensed`
Steps to reproduce:
-------------------
* Install **sale_management** and **hr_expense**
* Go to **Settings**
* Under `Customer Invoices`, enable `Intrastat` -> Save
* Under `Analytics`, enable `Analytic Accounting`
* Go to **Sales**
* Create 3 products
* Product 1: Default
* Product 2:
* Enable `Can be Expensed`
* Select `At cost` for Re-invoice expenses
* Product 3:
* Enable `Can be Expensed`
* Select `At cost` for Re-invoice expenses
* Disable `Can be expensed`
* For each product, repeat:
* Create a quotation, select a customer
* Add the product
* Confirm
* Select tab `Other Info`
* Check the analytic account
**Observations:**
* Product 1: No analytic account created
* Product 2: Analytic account created
* Product 3: Analytic account created
Why the fix:
------------
The creation of the analytic account depends on the value of `expense_policy`. When the value is `no`, no analytic account is created. Whereas when the value is `cost`, an analytic account is created.
https://github.com/odoo/odoo/blob/57ad9c05014ca0219d7892c1ff8a2e949fab3c49/addons/sale/models/sale_order.py#L853-L856
In this workflow, `expense_policy` is visible only when `Can be expensed` is enabled. If you select an `expense_policy` then disable `Can be expensed`, the value for the `expense_policy` stays as previously selected.
https://github.com/odoo/odoo/blob/3e320ffe0ff4d1c6bb7d0314f36dd13ad1cf23f4/addons/sale_expense/models/product_template.py#L33-L41
opw-3706305
Forward-Port-Of: odoo/odoo#154153This update corrects where permission groups are defined for analytic account fields, moving them from the account module to the analytic module where they belong. Additionally, the balance information is now visible to all users regardless of their read-only permissions, since balance is independent of credit/debit access controls.
Original PR description
The fields in analytic have a group which is defined in account. It's okay to show them in analytic module only (for example from project) for people having the rights to see analytic. We also show balance now, even if you don't have the group 'readonly', because it's an information that is independent of credit/debit notion. Linked to runbot error 59222 (will need to remove the group in the test) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#158994 Forward-Port-Of: odoo/odoo#156349
A Norwegian translation error was preventing sales confirmation emails from being sent properly. The issue occurred because part of the email template code was incorrectly translated, causing the template to fail rendering. This fix corrects the translation to ensure customers receive their order confirmations.
Original PR description
Issue ----- The sale confirmation mail template is not rendered because a part of code is translated. Note: there's currently no Norwegian translation on Transifex for this version opw-3809578 Forward-Port-Of: odoo/odoo#158770
A test in the Purchase MRP module was using incorrect field references that could cause validation issues. This fix corrects the test to use the proper field names, ensuring the test accurately validates the system's behavior when processing purchase orders with backorders.
Original PR description
this commit https://github.com/odoo/odoo/pull/158788/commits/07e2fca9e39e9c32182f10bae6ba814a4241b6bf uses `qty_done` instead of `quantity` in test `test_valuation_with_backorder`
This fix corrects how loyalty program discounts are calculated when taxes are applied to products. Previously, the system was incorrectly calculating discount amounts without properly accounting for included taxes, resulting in discounts that were larger than intended. Now the discount calculation properly adjusts for tax-inclusive pricing to ensure customers receive the exact discount value they earned through loyalty points.
Original PR description
Create a Loyalty program: - Program Type: Loyalty Cards - Rules: 0.01 per $ spent - Reward: 1.00 per point on cheapest product Make a SO with total 339 Loyalty Card will get 3.39 points Make a SO with line having - Unit Price 140 - Tax 15% - Total will be 161 Hit Promotions Issue: The system will add a discount line with unit price 5.0. With 15% taxes applied the total discount will be 5.75 While it should be 5 Order 1, Total with tax 339 => 3.39 loyalty points Order 2, Total with tax 161 => 1.41 loyalty points from current order \+ 3.39 from past order = 5.00 total loyalty points When applying the discount on Order 2 the system converts 5 points to 5$, but considering 15% tax included, the price unit of the discount line should be 4.35 opw-3642795 Forward-Port-Of: odoo/odoo#157125
A previous fix for calculating shipping volume and weight was causing compatibility issues with custom extensions. This update restores the original method structure while maintaining the weight and volume calculation fix by using an alternative technical approach. This ensures existing customizations continue to work without disruption.
Original PR description
36e6728b2cac87c7cd922001be0222688ad52abb fixed an issue where the volume and weight were incorrectly computed for carriers based on rules. But it was done by changing the method api, which seems to break some custom modules using/extending the modified methods. This commit reverts the API change, conveying the needed information through the context for now (the api change will be done in master only). opw-3826165 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#159181 Forward-Port-Of: odoo/odoo#159091
This fix removes an unnecessary filter that was significantly slowing down the task view in sales projects. The filter was redundant and caused the system to perform unnecessary searches, resulting in a 400x performance improvement (from 15 seconds down to 39 milliseconds). Users will now see task lists load much faster when viewing tasks associated with sales orders.
Original PR description
Since revision 81b5ef93a773b94a4e3770632469c692b0ff57fa, adding by default the filter `sale_order_id` which does: ```xml <field name="sale_order_id" string="Sale Order" filter_domain="['|',…
Since revision 81b5ef93a773b94a4e3770632469c692b0ff57fa, adding by default the filter `sale_order_id`
which does:
```xml
<field name="sale_order_id" string="Sale Order"
filter_domain="['|', ('sale_order_id', 'ilike', self), ('sale_line_id', 'ilike', self)]"
/>
```
becomes useless, because the final domain, with that `[('id', 'in', self.tasks_ids.ids)]` becomes:
```py
[
"&",
"&",
"&",
[
"project_id",
"!=",
false
],
[
"display_in_project",
"=",
true
],
[
"id",
"in",
[
3341211,
3526685,
3692221
]
],
"|",
[
"sale_order_id",
"ilike",
"SO2023/123456"
],
[
"sale_line_id",
"ilike",
"SO2023/123456"
]
]
```
which makes an "AND" connection between the task ids domain leaf and the sale order name ilike leaves, and all these task ids will come from these SO names, making the AND useless.
In addition to be useless, it downgrades the performance. On Odoo.com,
- with the filter `sale_order_id`: 15473 ms
- without the filter `sale_order_id`: 39ms
On the below screenshot:
The first request is with the filter `sale_order_id`
The second request is without the filter `sale_order_id`
opw-3752003
Forward-Port-Of: odoo/odoo#159115
Forward-Port-Of: odoo/odoo#158898This fix resolves an issue where QR codes printed on point of sale receipts were too small to scan on iOS devices. The QR code size has been adjusted to ensure it displays at a readable size when printed from iOS, improving the customer experience and receipt functionality.
Original PR description
Current behavior: When printing a receipt with a QR code on an iOS device, the QR code was too small and couldn't be scanned Steps to reproduce: - Setup an ePos printer for the PoS - Activate QRCode on receipt option - Start a PoS session on an iOS device - Add some product to the order and validate it - On the receipt screen click on the print button - Try to scan the QR Code on the ticket (it's probably too small) Note: If you don't have an iOS device you can use browserstack and use ngrok to expose your local server to the internet and connect to it on browserstack. You can do the same process to expose the printer so that you will be able to print from browserstack. opw-3788988 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#157423
This update removes a broken email sending method in the Partner module that has been non-functional since version 14.5. The underlying email functionality it relied on was removed years ago, but this method was accidentally left behind. Removing it prevents confusion and potential errors from attempting to use this obsolete feature.
Original PR description
The underlying `odoo.tools.email_send` was removed in 82de620424e22f9ca7cb9768db638c3a2b4f9318 (merged in 14.5) but this callsite was missed, this method has been broken ever since. Forward-Port-Of: odoo/odoo#159113
Estonia's default tax rate increased from 20% to 22% in 2024, and while the tax report was updated to reflect this change, the calculation formula was still using the old 20% rate. This fix corrects the tax computation formula to use the new 22% rate, ensuring accurate tax reporting for Estonian businesses.
Original PR description
In the beginning of 2024, the default tax of 20% in Estonia was changed by 22% (with the 20% still supported as a legacy) [1]. With that change, the tax report was also updated so the line previously containing the taxable amount at 20% now contains the taxable amount at 22%. However, the formula computing the tax amount itself was not updated to reflect this change and was still computing the tax by multiplying the taxable amount by 0.2. This fix corrects the tax computation in the report. [1] ec25405367eaeca6bdd1f54e2a09fe6b93b8a4b6 [opw-3815147](https://www.odoo.com/web#id=3815147&cids=1&model=project.task&view_type=form) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#159154
When creating a new invoice, the browser tab title was showing confusing technical information (NewId_0x7f545c9d6980) alongside the invoice name. This fix removes that unnecessary technical identifier so users see a clean, professional tab title like "Draft Invoice" instead.
Original PR description
Steps to reproduce ================== - Create a new Invoice => The tab title is `Odoo - Draft Invoice (* NewId_0x7f545c9d6980)` Cause of the issue ================== In 17, the display_name is computed for the tab title https://github.com/odoo/odoo/blob/82fd8e702588d2cc5bdad474ed21188257cc7397/addons/web/static/src/views/form/form_controller.js#L342 opw-3794671
This fix addresses a flaky test in the scheduled jobs system that was producing inconsistent results. The issue occurred because data was being flushed at the wrong time, causing conflicting settings to override each other. By reordering when the data flush happens, the test now runs reliably every time.