Friday, August 30, 2024
34 changes · saas-17.4
Enhancements to existing features
This update removes an unnecessary calculation step in the Brazilian AvaTax integration. It keeps the same business outcome while simplifying processing and reducing avoidable internal work.
Original PR description
The values computed in `super()._compute_l10n_br_goods_operation_type_id()` are immediately nullified by the successive `self.l10n_br_goods_operation_type_id = False`.
This update removes an unnecessary calculation step in the Brazilian AvaTax integration. It keeps the final behavior the same while making the related tax processing logic simpler and more efficient.
Original PR description
The values computed in `super()._compute_l10n_br_goods_operation_type_id()` are immediately nullified by the successive `self.l10n_br_goods_operation_type_id = False`. Well this is my impression, anyways. Something I'm missing?
Resolved issues and error corrections
This fix restores the ability to import translation files when setting up or updating languages. It resolves a form validation issue caused by a required hidden field, reducing disruption for teams managing multilingual Odoo databases.
Original PR description
Same missing required invisible field issue as mentioned in odoo/odoo#178175 opw-4139872 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
Miscellaneous changes
The vies check service may limit ip addresses when: - checking too many vat numbers per day - checking the same vat number multiple times - checking too many invalid number --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#178219
Original PR description
The vies check service may limit ip addresses when: - checking too many vat numbers per day - checking the same vat number multiple times - checking too many invalid number --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#178219
The Kanban view header now places the quick create and configuration buttons on the right side as intended. This fixes a visual alignment issue, making the interface clearer and more consistent for users.
Original PR description
Since [1], the alignment of the quick create and config button in a kanban was not correct. It was aligned to the left. Now, the alignment is correctly to the right of the kanban header. [1] : https://github.com/odoo/odoo/commit/f486bca505cb6ef9bf477e5d02d06c420b27de56
This fix keeps the top bar hidden after a user turns it off, even when switching between task views. It prevents the interface from unexpectedly showing the top bar again, making navigation more consistent and less confusing.
Original PR description
Currently, there is a strange behavior with the following use case: - open project app - select any project - press the top bar button - add any items to the top bar - click on the button to switch to the new action - go back to the 'tasks' view using the top bar. - remove the top bar by pressing the slider button - switch from the gantt view to any other view of the task. (e.a the list view) expected behavior: the list view is displayed, the top bar is not current behavior: the list view is displayed, the top bar is displayed too source of the issue: By clicking on the top bar to switch action, this sets the 'actionParentId' param from the env.config. With this param set, the setup of the control panel set the showEmbedded to True by default when loading a new view. task-4100301 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix restores the missing WhatsApp notification type for event communications. It ensures event-related WhatsApp messages can be scheduled and recognized correctly, preventing missed or misclassified notifications.
### Description of the issue/feature this PR addresses: 1. Add validation to CI and NIE identification types. 2. Improve the RUT message to more clear message about the expected format. Before this change only RUT document type was validated. With this new change we are able to validate also NIE and CI Uruguayan document types ### Current behavior before PR: 1. Trying to set an invalid NIE to a contact, there is not warning for the user and we let the user to store the number. 2. R
Original PR description
### Description of the issue/feature this PR addresses: 1. Add validation to CI and NIE identification types. 2. Improve the RUT message to more clear message about the expected format. Before this…
### Description of the issue/feature this PR addresses: 1. Add validation to CI and NIE identification types. 2. Improve the RUT message to more clear message about the expected format. Before this change only RUT document type was validated. With this new change we are able to validate also NIE and CI Uruguayan document types ### Current behavior before PR: 1. Trying to set an invalid NIE to a contact, there is not warning for the user and we let the user to store the number. 2. RUT: If we set an invalid number we receive the warning but the suggested format is not ok  ### Desired behavior after PR is merged: 1. If invalid RUT: improve error message:  2. If we set an invalid NIE to a contact we receive message warning that is not a valid one  --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#177634 Forward-Port-Of: odoo/odoo#173451
In commit https://github.com/odoo/odoo/commit/513dde64c736f1ff9141825b06c93666b67131db, we changed the field from `product_qty` to `quantity`, however, the latter use the move's UoM instead of the product's UoM. With this commit, we convert the quantities to the product's UoM to ensure the correct quantity is used. Forward-Port-Of: odoo/odoo#178226
Original PR description
In commit https://github.com/odoo/odoo/commit/513dde64c736f1ff9141825b06c93666b67131db, we changed the field from `product_qty` to `quantity`, however, the latter use the move's UoM instead of the product's UoM. With this commit, we convert the quantities to the product's UoM to ensure the correct quantity is used. Forward-Port-Of: odoo/odoo#178226
When uninstalling a module, a wizard displays the dependent modules that will also be uninstalled if the user confirms. By default, only the applications are displayed. This commit adds the imported modules to the default list to prevent unforeseen issues. Task-4144690 Forward-Port-Of: odoo/odoo#178251
Original PR description
When uninstalling a module, a wizard displays the dependent modules that will also be uninstalled if the user confirms. By default, only the applications are displayed. This commit adds the imported modules to the default list to prevent unforeseen issues. Task-4144690 Forward-Port-Of: odoo/odoo#178251
In commit [1], the carousel controls have been deactivated in edit mode, in order to control the carousel sliding manually so everything is done in the mutex. This was done to avoid asynchronous issues and to have a correct history when using the carousel options. However, these controls are also blocked in translate mode, because it is considered as if it was in edit mode, which should not be the case. This made it impossible to translate the other slides, since we cannot slide the carousel
Original PR description
In commit [1], the carousel controls have been deactivated in edit mode, in order to control the carousel sliding manually so everything is done in the mutex. This was done to avoid asynchronous issues and to have a correct history when using the carousel options. However, these controls are also blocked in translate mode, because it is considered as if it was in edit mode, which should not be the case. This made it impossible to translate the other slides, since we cannot slide the carousel anymore. This commit fixes this by not deactivating the carousel controls if we are in translate mode. Steps to reproduce: - Install an other language. - In edit mode, drop the "Carousel" or the "Quotes" snippet and save. - Change the language of the website and translate it. - Try to slide the carousel. => It is impossible. [1]: https://github.com/odoo/odoo/commit/93ec3ac285dc9ffd363e185a1dc238c6135d79dd opw-4134824 Forward-Port-Of: odoo/odoo#178252
* When fwd https://github.com/odoo/odoo/pull/156349 , we forgot to adapt with change in >=17.0 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#177702
Original PR description
* When fwd https://github.com/odoo/odoo/pull/156349 , we forgot to adapt with change in >=17.0 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#177702
Steps to reproduce: - Install Sign - Open Sign, add a document and put a signature box - Make the sign box have a weird aspect ratio (very short and super wide for example) Issues: When you sign with the frame, the frame will be partially hidden making the hash invisible. Solution: Put the container back just like in the 16.0, that way we don't have the weird CSS behavior that we had previously. opw-4042289 Forward-Port-Of: odoo/odoo#177500 Forward-Port-Of: odoo/odoo#175819
Original PR description
Steps to reproduce: - Install Sign - Open Sign, add a document and put a signature box - Make the sign box have a weird aspect ratio (very short and super wide for example) Issues: When you sign with the frame, the frame will be partially hidden making the hash invisible. Solution: Put the container back just like in the 16.0, that way we don't have the weird CSS behavior that we had previously. opw-4042289 Forward-Port-Of: odoo/odoo#177500 Forward-Port-Of: odoo/odoo#175819
Before this commit, recurrent events created with the 'All Day' option were duplicating the first event of the recurrence in Google side. This was happening because we wrongly synchronized the single event with Google before the synchronization of its recurrence (which already synchronize the events in Google side itself). After this commit, the recurrence is created normally using the 'All Day' option. We achieve that by skipping the useless synchronization we were doing in the single event:
Original PR description
Before this commit, recurrent events created with the 'All Day' option were duplicating the first event of the recurrence in Google side. This was happening because we wrongly synchronized the single event with Google before the synchronization of its recurrence (which already synchronize the events in Google side itself). After this commit, the recurrence is created normally using the 'All Day' option. We achieve that by skipping the useless synchronization we were doing in the single event: only the recurrence must be synchronized in this specific flow. task-3768121 Forward-Port-Of: odoo/odoo#177073 Forward-Port-Of: odoo/odoo#166885
## Pull Request HOOT (PRHOOT) - part 22 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
Original PR description
## Pull Request HOOT (PRHOOT) - part 22 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:…
## Pull Request HOOT (PRHOOT) - part 22 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 Part 13: https://github.com/odoo/odoo/pull/158384 / https://github.com/odoo/enterprise/pull/59019 Part 14: https://github.com/odoo/odoo/pull/158916 Part 15: https://github.com/odoo/odoo/pull/160292 / https://github.com/odoo/enterprise/pull/59971 Part 15.5: https://github.com/odoo/odoo/pull/166463 Part 16: https://github.com/odoo/odoo/pull/166311 Part 17: https://github.com/odoo/odoo/pull/168328 Part 18: https://github.com/odoo/odoo/pull/171004 / https://github.com/odoo/enterprise/pull/65657 Part 19: https://github.com/odoo/odoo/pull/171242 / https://github.com/odoo/enterprise/pull/65767 Part 20: https://github.com/odoo/odoo/pull/173332 / https://github.com/odoo/enterprise/pull/66895 Part 21: https://github.com/odoo/odoo/pull/174337 Enterprise: https://github.com/odoo/enterprise/pull/68721 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/odoo#176777
Steps to reproduce: - wrap a pivot function inside a IFERROR e.g. =IFERROR(PIVOT("1", "probability"), 42) - reload the spreadsheet - before the pivot is loaded (throttle the network in the dev tools): right click the cell - click on "See records" menu item => boom Task: 3847477 X-original-commit: odoo/enterprise@31401c75baa4252917fe5d808be0abd5fc23a906 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#167559 Forwa
Original PR description
Steps to reproduce:
- wrap a pivot function inside a IFERROR e.g. =IFERROR(PIVOT("1", "probability"), 42)
- reload the spreadsheet
- before the pivot is loaded (throttle the network in the dev tools): right click the cell
- click on "See records" menu item => boom
Task: 3847477
X-original-commit: odoo/enterprise@31401c75baa4252917fe5d808be0abd5fc23a906
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#167559
Forward-Port-Of: odoo/odoo#162568Currently, when various timestamps in Odoo are processed through the `DeserializeDate` function, the offset is being doubled by mistake. The Odoo timestamps are passed as strings which have already been converted to UTC. If a user inputs a `DateTime` on a pricelist for instance, that time will be converted to its UTC equivalent before being converted to a string. The issue arises when we try to parse that string in the frontend during a PoS session. Odoo will correctly parse the timestamp, howev
Original PR description
Currently, when various timestamps in Odoo are processed through the `DeserializeDate` function, the offset is being doubled by mistake. The Odoo timestamps are passed as strings which have already…
Currently, when various timestamps in Odoo are processed through the `DeserializeDate` function, the offset is being doubled by mistake. The Odoo timestamps are passed as strings which have already been converted to UTC. If a user inputs a `DateTime` on a pricelist for instance, that time will be converted to its UTC equivalent before being converted to a string. The issue arises when we try to parse that string in the frontend during a PoS session. Odoo will correctly parse the timestamp, however through the `DeserializeDate` function it calls the `FromSQL` function with the parameter `zone: 'default'` which makes Odoo process this timestamp as being in the `SystemZone` (which is used by default in Luxon) instead of correctly recognizing that it is already in UTC. Thus, it will offset it again, which causes the functionality to fail This commit allows the timezone in `DeserializeDate` to be passed as a parameter, so in these cases we can pass the correct timezone and avoid this issue. Task-ID: 4106252 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#177976 Forward-Port-Of: odoo/odoo#176866
This change fixes 2 related issues: - If a user went to their cart after setting their order's delivery method to "pickup in store", they'd get an error if the store's partner was incomplete. Indeed, going to the cart would trigger the shipping partner's (i.e. the store partner's) validation. Since the shipping method is cleared anyway when going to the cart, we now now also clear the shipping address if the delivery method was "pickup in store". - When creating a new SO, we automatically set
Original PR description
This change fixes 2 related issues: - If a user went to their cart after setting their order's delivery method to "pickup in store", they'd get an error if the store's partner was incomplete. Indeed,…
This change fixes 2 related issues: - If a user went to their cart after setting their order's delivery method to "pickup in store", they'd get an error if the store's partner was incomplete. Indeed, going to the cart would trigger the shipping partner's (i.e. the store partner's) validation. Since the shipping method is cleared anyway when going to the cart, we now now also clear the shipping address if the delivery method was "pickup in store". - When creating a new SO, we automatically set its shipping/invoice partners to those from the last SO. If the last SO had a "pickup in store" delivery method, then the store's partner was used as the new SO's shipping partner. If the user tried to edit the address, they'd get an access error. Now, we don't use the last SO's shipping/invoice partner if they don't belong to the current partner (i.e. if they belong to the store). opw-4126140 opw-4114139 opw-4115510 opw-4117520 opw-4109625 opw-4115415 opw-4143237 opw-4123382 opw-4136888 opw-4125807 Forward-Port-Of: odoo/odoo#178338
we had some issues `object.email` translated `object.e-mail`
Original PR description
we had some issues `object.email` translated `object.e-mail`
On linux and Windows, CTRL + left clic on links, e.g. a customer on an invoice opens a new tab. This browser behavior is similar with regular links using Command + Left clic on MacOS. It wasn't working for many2one links in Odoo because the clic was captured and prevented the browser default behavior. It was not captured only for the `ctrlKey` currently. This revision adds the `metaKey` in addition to the `ctrlKey` to the non-capture condition. There are similar conditions a bit ev
Original PR description
On linux and Windows, CTRL + left clic on links, e.g. a customer on an invoice opens a new tab. This browser behavior is similar with regular links using Command + Left clic on MacOS. It wasn't…
On linux and Windows, CTRL + left clic on links, e.g. a customer on an invoice opens a new tab. This browser behavior is similar with regular links using Command + Left clic on MacOS. It wasn't working for many2one links in Odoo because the clic was captured and prevented the browser default behavior. It was not captured only for the `ctrlKey` currently. This revision adds the `metaKey` in addition to the `ctrlKey` to the non-capture condition. There are similar conditions a bit everywhere in the code: - https://github.com/odoo/odoo/blob/9beccc94ba6c140d6e1eb43c34d811c424f5ea2c/addons/barcodes/static/src/js/barcode_events.js#L170-L171 - https://github.com/odoo/odoo/blob/9beccc94ba6c140d6e1eb43c34d811c424f5ea2c/addons/mail/static/src/models/user_setting/user_setting.js#L163 - https://github.com/odoo/odoo/blob/9beccc94ba6c140d6e1eb43c34d811c424f5ea2c/addons/web/static/src/core/hotkeys/hotkey_service.js#L250 - https://github.com/odoo/odoo/blob/9beccc94ba6c140d6e1eb43c34d811c424f5ea2c/addons/web_editor/static/src/js/wysiwyg/wysiwyg.js#L1705-L1710 - https://github.com/odoo/odoo/blob/9beccc94ba6c140d6e1eb43c34d811c424f5ea2c/addons/website_slides/static/src/js/slides_embed.js#L178 - https://github.com/odoo/enterprise/blob/6dc662dfca8e1d277df19aa377bcdc761f7e7bf3/documents/static/src/js/documents_controller_mixin.js#L975 - https://github.com/odoo/enterprise/blob/6dc662dfca8e1d277df19aa377bcdc761f7e7bf3/documents_spreadsheet/static/src/js/o_spreadsheet/o_spreadsheet.js#L31440 - https://github.com/odoo/enterprise/blob/6dc662dfca8e1d277df19aa377bcdc761f7e7bf3/timesheet_grid/static/src/js/timesheet_grid/timesheet_timer_grid_renderer.js#L301 - https://github.com/odoo/enterprise/blob/6dc662dfca8e1d277df19aa377bcdc761f7e7bf3/web_enterprise/static/src/webclient/home_menu/home_menu.js#L434 - https://github.com/odoo/enterprise/blob/6dc662dfca8e1d277df19aa377bcdc761f7e7bf3/web_gantt/static/src/js/gantt_renderer.js#L163 - https://github.com/odoo/enterprise/blob/6dc662dfca8e1d277df19aa377bcdc761f7e7bf3/web_gantt/static/src/js/gantt_row.js#L159 Unfortunately, given the nature of this behavior (requires a Command keystroke + check that a new tab is opened), it cannot really be tested in a unit test, not even a web tour. Forward-Port-Of: odoo/odoo#178314 Forward-Port-Of: odoo/odoo#178268
Create group of tax 5% + 5% and create invoice with two lines with same tax and one line with analytic and another line without analytic then tax_details is wrong because tax.analytic is NULL Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#178390
Original PR description
Create group of tax 5% + 5% and create invoice with two lines with same tax and one line with analytic and another line without analytic then tax_details is wrong because tax.analytic is NULL Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#178390
This test was underministically failing due to a combination of two factors: - The domain chosen for the test is selected by ```py domain = list(iap_tools._MAIL_DOMAIN_BLACKLIST)[0] ``` which was undeterministic since `iap_tools._MAIL_DOMAIN_BLACKLIST` is a set. - Since commit 02b5d47, a distinction was made between email providers `_MAIL_PROVIDERS` and the domain blacklist `_MAIL_DOMAIN_BLACKLIST`. The test used `_MAIL_DOMAIN_BLACKLIST` instead of `_MAIL_PROVIDERS`, it should have been
Original PR description
This test was underministically failing due to a combination of two factors: - The domain chosen for the test is selected by ```py domain = list(iap_tools._MAIL_DOMAIN_BLACKLIST)[0] ``` which was undeterministic since `iap_tools._MAIL_DOMAIN_BLACKLIST` is a set. - Since commit 02b5d47, a distinction was made between email providers `_MAIL_PROVIDERS` and the domain blacklist `_MAIL_DOMAIN_BLACKLIST`. The test used `_MAIL_DOMAIN_BLACKLIST` instead of `_MAIL_PROVIDERS`, it should have been adapted. The only difference between the two, at the moment, is the addition of "odoo.com" in the domain blacklist. When that domain is selected, the test crashes. There is approximately a 1/124 chance of that happening. Forward-Port-Of: odoo/odoo#177935
When an editable content is dropped in the website form, the editable elements identification and adaptation happens on `start()` (async). In a normal user interaction context, the dropped content would be set as editable in time, but when doing automated testing, we need to make sure the dropped content has `[contenteditable=true]` before editing its content. Remark: This commit also removes the `_keydown()` test function from the tour (since it still uses the deprecated `execCommand
Original PR description
When an editable content is dropped in the website form, the editable elements identification and adaptation happens on `start()` (async). In a normal user interaction context, the dropped content would be set as editable in time, but when doing automated testing, we need to make sure the dropped content has `[contenteditable=true]` before editing its content. Remark: This commit also removes the `_keydown()` test function from the tour (since it still uses the deprecated `execCommand()`) and replaces it with a simple `run: "text ..."`. runbot-64816 Forward-Port-Of: odoo/odoo#177809 Forward-Port-Of: odoo/odoo#165361
Commit that introduced the issue: https://github.com/odoo/odoo/commit/2050328a37ed5dd7639273bcd60eb5006bd98cfb Issue: ====== We can't scroll to anchor link until the animation is over in rtl language. Steps to reproduce the issue: ============================= - Go to a blanck web page - Add a form on the top - Create a link for it using the sidebar (it will be #Form) - Add text block after it - Add heading block - Add any animation but make sure to add a delay (3s for example) an
Original PR description
Commit that introduced the issue: https://github.com/odoo/odoo/commit/2050328a37ed5dd7639273bcd60eb5006bd98cfb Issue: ====== We can't scroll to anchor link until the animation is over in rtl…
Commit that introduced the issue: https://github.com/odoo/odoo/commit/2050328a37ed5dd7639273bcd60eb5006bd98cfb Issue: ====== We can't scroll to anchor link until the animation is over in rtl language. Steps to reproduce the issue: ============================= - Go to a blanck web page - Add a form on the top - Create a link for it using the sidebar (it will be #Form) - Add text block after it - Add heading block - Add any animation but make sure to add a delay (3s for example) and duration (2s for example) - Add a text and a button after the heading - Add the link `#Form` to the button - Save - Reload the page and choose arabic language for the website (not the user) - The scroll down and click on the button, nothing happens until the animation is over and then when you click the page scrolls to the form. Origin of the issue: ==================== By default the value `overflow-y=visible` so in `ltr` since we don't update the overlow it stays by defaylt and the JQuery doesn't detect it as scrollable. Now in `rtl` we add `overflow-x:hidden` which update the value of `overflow-y` to `auto` which makes the JQuery detect it as scrollable which explains the difference of behavior between the two directions. Since the closestScrollable of the element isn't the same in the two directions, then in `rtl` it will produce different offset in `scrollTo` of JQuery. opw-4053513 Forward-Port-Of: odoo/odoo#177082
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#178221
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#178221
--- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#176435
Original PR description
--- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#176435
Steps to reproduce: In field service, have a project on which you have to sell 3 of item A. Item a is tracked by serial number and the delivery route is in 2 steps. From stock to output and from output to customer. On the sale order make sure you have 3 separate lines of 1 quantity of product A separated or not by sections. Confirm this one. This will create two pickings. One picking linked to a global stock move for 3 units from stock to output. A second picking linked to 3 stock moves ea
Original PR description
Steps to reproduce: In field service, have a project on which you have to sell 3 of item A. Item a is tracked by serial number and the delivery route is in 2 steps. From stock to output and from output to customer. On the sale order make sure you have 3 separate lines of 1 quantity of product A separated or not by sections. Confirm this one. This will create two pickings. One picking linked to a global stock move for 3 units from stock to output. A second picking linked to 3 stock moves each linked to a sale line id. Prioritise the first one by starring it. Now go back to the project and mark is as done. Had to redo the tests as from 17.2 one picking is generated at a time. Here we modify rules to create the two pickings. We have to do this to mimic customers migrating from prior versions of 17.2 to later versions. Original closed PR: https://github.com/odoo/enterprise/pull/61079 OPW-4088696 Forward-Port-Of: odoo/enterprise#68630
The s/h in column B of the export of the csv for DateV should be in uppercase. task-4131986 Forward-Port-Of: odoo/enterprise#68868 Forward-Port-Of: odoo/enterprise#68795
Original PR description
The s/h in column B of the export of the csv for DateV should be in uppercase. task-4131986 Forward-Port-Of: odoo/enterprise#68868 Forward-Port-Of: odoo/enterprise#68795
Steps to reproduce: - Install Sign - Open Sign, add a document and put a signature box - Make the sign box have a weird aspect ratio (very short and super wide for example) Issues: When you sign with the frame, the frame will be partially hidden making the hash invisible. Solution: Put the container back just like in the 16.0, that way we don't have the weird CSS behavior that we had previously. opw-4042289 Forward-Port-Of: odoo/enterprise#68737 Forward-Port-Of: odoo/enterprise#68
Original PR description
Steps to reproduce: - Install Sign - Open Sign, add a document and put a signature box - Make the sign box have a weird aspect ratio (very short and super wide for example) Issues: When you sign with the frame, the frame will be partially hidden making the hash invisible. Solution: Put the container back just like in the 16.0, that way we don't have the weird CSS behavior that we had previously. opw-4042289 Forward-Port-Of: odoo/enterprise#68737 Forward-Port-Of: odoo/enterprise#68015
## Pull Request HOOT (PRHOOT) - part 22 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
Original PR description
## Pull Request HOOT (PRHOOT) - part 22 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:…
## Pull Request HOOT (PRHOOT) - part 22 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 Part 13: https://github.com/odoo/odoo/pull/158384 / https://github.com/odoo/enterprise/pull/59019 Part 14: https://github.com/odoo/odoo/pull/158916 Part 15: https://github.com/odoo/odoo/pull/160292 / https://github.com/odoo/enterprise/pull/59971 Part 15.5: https://github.com/odoo/odoo/pull/166463 Part 16: https://github.com/odoo/odoo/pull/166311 Part 17: https://github.com/odoo/odoo/pull/168328 Part 18: https://github.com/odoo/odoo/pull/171004 / https://github.com/odoo/enterprise/pull/65657 Part 19: https://github.com/odoo/odoo/pull/171242 / https://github.com/odoo/enterprise/pull/65767 Part 20: https://github.com/odoo/odoo/pull/173332 / https://github.com/odoo/enterprise/pull/66895 Part 21: https://github.com/odoo/odoo/pull/174337 Community: https://github.com/odoo/odoo/pull/176777 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#68721
Before this PR: There are two problems: first, if you have a line discount like this: <img width="350" alt="Captura de pantalla 2024-03-27 a la(s) 09 48 55" src="https://github.com/odoo/enterprise/assets/382893/7564b133-c6e9-4bab-97f3-d8a0a2634fe5"> The calculation made by Odoo is: 319319 * 21.35 / 100 = 68175 which does not match the amount placed in "DescuentoMonto". In this case, it is 68173 (difference of 2 CLP) which is why it is better to prioritize the discount amount instead of the
Original PR description
Before this PR: There are two problems: first, if you have a line discount like this: <img width="350" alt="Captura de pantalla 2024-03-27 a la(s) 09 48 55"…
Before this PR: There are two problems: first, if you have a line discount like this: <img width="350" alt="Captura de pantalla 2024-03-27 a la(s) 09 48 55" src="https://github.com/odoo/enterprise/assets/382893/7564b133-c6e9-4bab-97f3-d8a0a2634fe5"> The calculation made by Odoo is: 319319 * 21.35 / 100 = 68175 which does not match the amount placed in "DescuentoMonto". In this case, it is 68173 (difference of 2 CLP) which is why it is better to prioritize the discount amount instead of the percentage in the XML, which is already rounding, leading to a problem. The second: if you have a surcharge in the line, like this: <img width="354" alt="Captura de pantalla 2024-03-27 a la(s) 09 52 40" src="https://github.com/odoo/enterprise/assets/382893/5a7ffa96-a2d9-498f-acf3-7003c95aa789"> Odoo ignores it. After the PR: The first issue is fixed by giving priority to the "DescuentoMonto" tag. The second issue is added as an improvement. Since Odoo does not have a column to show the surcharge separated in the line, we are taking advantage of the feature that supports negative discounts in the line to put that surcharge as negative. Forward-Port-Of: odoo/enterprise#65842 Forward-Port-Of: odoo/enterprise#59532
we had some issues `object.email` translated `object.e-mail`
Original PR description
we had some issues `object.email` translated `object.e-mail`
Have a partner in need of action with the followup level configured to Send an Email, with 'Automatic' enabled Case 1: - Send the followup manually - Reply to the follouwp mail - Message will be posted as log note but the system link the message with the previous one[1], where user is the author and will be automatically notified Case 2: - Wait for the cron to send followup automatically - Reply to the followup mail - Message will be posted as log note but since OdooBot is the author
Original PR description
Have a partner in need of action with the followup level configured to Send an Email, with 'Automatic' enabled Case 1: - Send the followup manually - Reply to the follouwp mail - Message will be posted as log note but the system link the message with the previous one[1], where user is the author and will be automatically notified Case 2: - Wait for the cron to send followup automatically - Reply to the followup mail - Message will be posted as log note but since OdooBot is the author of the previous message no user will receive any notification With this commit we make use of the followup responsible when sending followup email automatically before defaulting to OdooBot [1] https://github.com/odoo/odoo/blob/fe4b2a6d08a450b281e7ac0676afd51a88dd6008/addons/mail/models/mail_thread.py#L1182 opw-4000835 Forward-Port-Of: odoo/enterprise#67391
Steps to reproduce the bug: - Create a storable product P1 with the following BoM: - Type: Subcontracting - Subcontractor: Azure Interior - Components: - C1: 1 unit (price of C1: $10) - Cost of P1: $10 - Create a purchase order: - Product: P1 - Quantity: 100 units - Confirm the purchase order. - Receive 99 units and create a backorder for 1 unit. - Go to Manufacturing > Reporting > Production Analysis. Problem: The "Total Subcontractin
Original PR description
Steps to reproduce the bug: - Create a storable product P1 with the following BoM: - Type: Subcontracting - Subcontractor: Azure Interior - Components: - C1: 1 unit (price of C1: $10) - Cost of P1:…
Steps to reproduce the bug:
- Create a storable product P1 with the following BoM:
- Type: Subcontracting
- Subcontractor: Azure Interior
- Components:
- C1: 1 unit (price of C1: $10)
- Cost of P1: $10
- Create a purchase order:
- Product: P1
- Quantity: 100 units
- Confirm the purchase order.
- Receive 99 units and create a backorder for 1 unit.
- Go to Manufacturing > Reporting > Production Analysis.
Problem:
The "Total Subcontracting Cost / Unit" is $40 instead of $20. This
occurs because, in the SQL query, when performing the left join
between `stock_move_move_rel` and `stock_move`, the moves appear
duplicated as they have the same `move_orig_id`. Consequently, when
calculating the total quantity, it results in
`(99 + 99) = 198 * $20 = $3960`, but the total is only divided by the
quantity of one move, leading to $3960 / 99 = $40.
opw-[4061947](https://www.odoo.com/web#id=4061947&view_type=form&model=project.task)
Forward-Port-Of: odoo/enterprise#68834
Forward-Port-Of: odoo/enterprise#68778