Tuesday, March 26, 2024
36 changes · saas-17.2
Resolved issues and error corrections
This fix ensures tests that depend on specific dates use the intended server date instead of an outdated default from 2019. It helps prevent false test failures and improves confidence in release quality without changing end-user behavior.
Original PR description
mock server date is by default in 2019, which can lead into unwanted behaviours. Mock the correct date to the server for those hard coded date tests.
Miscellaneous changes
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:- . 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:-  Forward-Port-Of: odoo/enterprise#59002
Com PR: https://github.com/odoo/odoo/pull/157897 --- We must disable the cache for the header when there are record links in it. When the runbot performs enterprise tests, "Helpdesk" appears in the header, which includes a record link. This commit removes record like urls in the menu before doing the performance test to prevent increasing the query count. opw-3694651 opw-3750925 opw-3781668 Forward-Port-Of: odoo/enterprise#59358 Forward-Port-Of: odoo/enterprise#58853
Original PR description
Com PR: https://github.com/odoo/odoo/pull/157897 --- We must disable the cache for the header when there are record links in it. When the runbot performs enterprise tests, "Helpdesk" appears in the header, which includes a record link. This commit removes record like urls in the menu before doing the performance test to prevent increasing the query count. opw-3694651 opw-3750925 opw-3781668 Forward-Port-Of: odoo/enterprise#59358 Forward-Port-Of: odoo/enterprise#58853
**Current behavior:** If a company belongs to a VAT Unit and a report is generated with that Unit selected, the PDF output will display the company VAT number instead of the VAT Unit number. **Expected behavior:** The VAT Unit number will be written to the PDF if a report is being generated with that option selected. **Steps to reproduce:** 1. Install l10n_be and in the company config for the default Belgian company, add a new VAT Unit and make the Belgian company part of it 2. In th
Original PR description
**Current behavior:** If a company belongs to a VAT Unit and a report is generated with that Unit selected, the PDF output will display the company VAT number instead of the VAT Unit number.…
**Current behavior:** If a company belongs to a VAT Unit and a report is generated with that Unit selected, the PDF output will display the company VAT number instead of the VAT Unit number. **Expected behavior:** The VAT Unit number will be written to the PDF if a report is being generated with that option selected. **Steps to reproduce:** 1. Install l10n_be and in the company config for the default Belgian company, add a new VAT Unit and make the Belgian company part of it 2. In the Accounting app, go to the `Tax Report` view under the `Reporting` menu 3. Select the newly created VAT Unit for the `Tax Unit` option in the top right of the view 4. Select the `PDF` button to print the report, observe that the `VAT:` label on the report shows the Company VAT number instead of the Unit's **Cause of the issue:** The XML template for the PDF report is only setup to show the company VAT number here. **Fix:** Use the selection for the `Tax Unit:` configuration to inform the VAT number that is shown on the final report. opw-3747319 Forward-Port-Of: odoo/enterprise#59240 Forward-Port-Of: odoo/enterprise#58361
*: website_twitter_wall This commit involves adjustments to a few images and SVG files to incorporate the new X (previously called Twitter) logo. related to: https://github.com/odoo/odoo/pull/148126 task-3463530 Forward-Port-Of: odoo/enterprise#59147 Forward-Port-Of: odoo/enterprise#53644
Original PR description
*: website_twitter_wall This commit involves adjustments to a few images and SVG files to incorporate the new X (previously called Twitter) logo. related to: https://github.com/odoo/odoo/pull/148126 task-3463530 Forward-Port-Of: odoo/enterprise#59147 Forward-Port-Of: odoo/enterprise#53644
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
## Issue: - when you create an appraisal and you click on 'send by email' and add some text on the body of the email, it doesn't appear nor in the chatter, nor in the email sent. ## Steps To Reproduce: - create an appraisal - click on SEND BY email - add email body - notice missing email body in the chatter. ## Solution: - add user_body to "_compute_body" dependencies to trigger it otherwise it wont be computed and body is kept empty. opw-3787796 Forward-Port-
Original PR description
## Issue:
- when you create an appraisal and you click on 'send by email' and add some text on the body of the email, it doesn't appear
nor in the chatter, nor in the email sent.
## Steps To Reproduce:
- create an appraisal
- click on SEND BY email
- add email body
- notice missing email body in the chatter.
## Solution:
- add user_body to "_compute_body" dependencies to trigger it otherwise it wont be computed and body is kept empty.
opw-3787796
Forward-Port-Of: odoo/enterprise#58374Before 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 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
Change adds inputs and rules used for calculating salary in UAE. task-3634461 Forward-Port-Of: odoo/enterprise#53553
Original PR description
Change adds inputs and rules used for calculating salary in UAE. task-3634461 Forward-Port-Of: odoo/enterprise#53553
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
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