Daily updates from Odoo
Navigate
Branch
Wednesday, August 21, 2024
55 changes
5 changes
Miscellaneous changes
__Current behavior before commit:__ When a mega menu has the class `o_mega_menu_container_size`, it is translated by 50% to the left because of this line [1]. However it shouldn't be if it is displayed inside a dropdown menu. __Description of the fix:__ Unset `transform` of `.o_mega_menu_container_size` when it is inside an `.o_extra_menu_items` element. __Steps to reproduce the issue on runbot:__ 1. Add a mega menu to the website 2. In the Editor, set Mega Menu > Size to `Narrow` a
Original PR description
__Current behavior before commit:__ When a mega menu has the class `o_mega_menu_container_size`, it is translated by 50% to the left because of this line [1]. However it shouldn't be if it is displayed inside a dropdown menu. __Description of the fix:__ Unset `transform` of `.o_mega_menu_container_size` when it is inside an `.o_extra_menu_items` element. __Steps to reproduce the issue on runbot:__ 1. Add a mega menu to the website 2. In the Editor, set Mega Menu > Size to `Narrow` and save 3. Resize the window just enough that a dropdown menu appear 4. Open the dropdown menu -> The mega menu is offset to the left opw-4021738 [1]: https://github.com/odoo/odoo/blob/9835632/addons/website/static/src/scss/website.scss#L1294 Forward-Port-Of: odoo/odoo#172438
Steps to reproduce the bug: - Create a storable product “P1” with BoM: - Component: C1 - Create a quality point: - Product: P1 - Operation: Manufacturing - Control per: Quantity - Control Frequency: All - Create a manufacturing order: - Product: P1 - Quantity: 20 - Confirm the MO - Set the qty producing 12 - click on the quality check: - Button Fail - Quantity: 5 - Valide the Mo and create a backorder - click on the quality check: - Button Fail - Quantity: 1 Problem: A traceb
Original PR description
Steps to reproduce the bug: - Create a storable product “P1” with BoM: - Component: C1 - Create a quality point: - Product: P1 - Operation: Manufacturing - Control per: Quantity - Control Frequency:…
Steps to reproduce the bug:
- Create a storable product “P1” with BoM: - Component: C1
- Create a quality point: - Product: P1 - Operation: Manufacturing - Control per: Quantity - Control Frequency: All
- Create a manufacturing order: - Product: P1 - Quantity: 20
- Confirm the MO
- Set the qty producing 12
- click on the quality check: - Button Fail - Quantity: 5
- Valide the Mo and create a backorder
- click on the quality check: - Button Fail - Quantity: 1
Problem:
A traceback is triggered:
```
File "/home/odoo/odoo V16/enterprise/quality_control/models/quality.py", line 370, in _move_line_to_failure_location
if not check._can_move_line_to_failure_location():
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/odoo V16/enterprise/quality_mrp/models/quality.py", line 49, in _can_move_line_to_failure_location
self.move_line_id = self.production_id.finished_move_line_ids.filtered(
^^^^^^^^^^^^^^^^^
File "/home/odoo/odoo V16/odoo/odoo/fields.py", line 1321, in __set__
write_value = self.convert_to_write(value, records)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/odoo V16/odoo/odoo/fields.py", line 3118, in convert_to_write
return value.id
^^^^^^^^
File "/home/odoo/odoo V16/odoo/odoo/fields.py", line 5154, in __get__
raise ValueError("Expected singleton: %s" % record)
ValueError: Expected singleton: stock.move.line(96, 98)
```
When we validate the MO to create the backorder, the `_split_productions`
function is called. This results in two move lines:
https://github.com/odoo/odoo/blob/4be8cac644c9471f98bf16e82825af0e9439e697/addons/mrp/models/mrp_production.py#L1837
The first one has a quantity of 15, which is the remaining quantity
to be processed, and the second line has a quantity of 5, which is the
quantity that has definitely failed. However, these two move lines are
supposed to be ordered first by the failed ones and then by the others.
Because, in the current situation, we take the move line with the
quantity of 15, reduce it by the 12 units processed in this MO,
leaving 3. As a result, we will have two remaining move lines:
3 + 5 (already failed), and both will be used in the backorder.
But if they were ordered by the failed ones first, we would subtract
12 from 5, resulting in -7, and then reduce the line with 15 - 7 = 8
in the move line that will be used in the backorder."
https://github.com/odoo/odoo/blob/4be8cac644c9471f98bf16e82825af0e9439e697/addons/mrp/models/mrp_production.py#L1848-L1858
opw-4064656
Forward-Port-Of: odoo/odoo#177041
Forward-Port-Of: odoo/odoo#175355**Version:** - 17.0 **Step to reproduce:** - open the Calendar and navigate to Configuration > Settings - add Google credentials and sync it - create an event and then pause the sync. - again create an event and unpause the sync with Google Calendar - event fails to update on Google Calendar **Issue:** Currently, when an event is created during the sync_pause period, the `_google_insert` function will not be called. After unpausing the sync, the event will return an empty Google
Original PR description
**Version:** - 17.0 **Step to reproduce:** - open the Calendar and navigate to Configuration > Settings - add Google credentials and sync it - create an event and then pause the sync. - again create an event and unpause the sync with Google Calendar - event fails to update on Google Calendar **Issue:** Currently, when an event is created during the sync_pause period, the `_google_insert` function will not be called. After unpausing the sync, the event will return an empty GoogleEvent ID. **Solution:** This PR enables the synchronization to restart automatically when unpausing the Google Calendar. task-3731607 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#156037
When a blog cover is edited, a tag option is displayed while there is no `tag_ids` inside the `blog.blog` model because the `o_wblog_post_page_cover` appears on both the `blog.blog` covers and on the `blog.post` covers. This commit hides the blog tags option if the model of the cover is `blog.blog`. Steps to reproduce: - Go to blogs. - Select the "Travel" blog. - Edit. - Select the blog's cover. => A tag option could be specified. opw-4107748 Forward-Port-Of: odoo/odoo#177077 Fo
Original PR description
When a blog cover is edited, a tag option is displayed while there is no `tag_ids` inside the `blog.blog` model because the `o_wblog_post_page_cover` appears on both the `blog.blog` covers and on the `blog.post` covers. This commit hides the blog tags option if the model of the cover is `blog.blog`. Steps to reproduce: - Go to blogs. - Select the "Travel" blog. - Edit. - Select the blog's cover. => A tag option could be specified. opw-4107748 Forward-Port-Of: odoo/odoo#177077 Forward-Port-Of: odoo/odoo#176510
At the moment, JP is added at the start of the tax scheme vals. In Japan and after 2023-10-01, the expected value in the company_id is the "Registration Number for Qualified Invoice purpose in Japan" which starts with a T and does not want JP prepended to it. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#177144
Original PR description
At the moment, JP is added at the start of the tax scheme vals. In Japan and after 2023-10-01, the expected value in the company_id is the "Registration Number for Qualified Invoice purpose in Japan" which starts with a T and does not want JP prepended to it. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#177144
29 changes
Resolved issues and error corrections
This fixes a stock delivery form issue where an unnecessary serial/lot creation field appeared when both selecting existing lots and creating new lots were enabled. Users now see the appropriate field when choosing serial numbers, reducing confusion during delivery processing.
Original PR description
Steps to reproduce the bug:
- Go to the delivery operation type:
- set to True "use_existing_lots" and "use_create_lots"
- Create a storable product “P1” tracked by SN
- Create a delivery with one unit of P1
- Confirm it
- Click on the detailed operation to select the serial number
Problem:
The 'Lot_name' field is displayed, but since the operation type
has both `use_existing_lots` and `use_create_lots` set to True,
the 'Lot_name' field should not be displayed.
https://github.com/odoo/odoo/blob/4da8c6ebca024b31278a946aef55cc37f0210b33/addons/stock/models/stock_move.py#L606-L610
https://github.com/odoo/odoo/blob/4da8c6ebca024b31278a946aef55cc37f0210b33/addons/stock/views/stock_move_views.xml#L294-L297
|
|
|
|
|
FYI: https://github.com/odoo/odoo/commit/b771eadf8f6a70cbbb01481f362c89b41796d671#diff-55c6314416a6a400da6acd5018d161a55eeeb0e3008fec8828121e3dd12be0ebL550
opw-[4113887](https://www.odoo.com/web#id=4113887&view_type=form&model=project.task)Sales orders with down payments taken through Point of Sale can now be invoiced without errors. This ensures draft invoices are created correctly when settling quotations that include POS down payments.
Original PR description
Steps to reproduce: - Sale > Quotations > New - Set customer and product - POS > Quotation/Order > Apply down payment > Pay - Sale > Quotation > Create invoice > Create draft Error because the down payment line is missing an account_id, as a result of this commit 50ce3ce1d98958241667d1122273abccd59874b7 we would pass account_id = False in vals_list sometimes, causing the account_id not to be filled in or inferred later. opw-4064906 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The screen-sharing button is now hidden during mail calls on mobile devices because current mobile browsers do not support this feature. This avoids misleading users into trying to enable permissions for something that cannot work on their device.
Original PR description
This feature is not available in mobile OS at the time of this commit [1]: - Safari on iOS 17.5 - Chrome for Android 127 - Firefox for Android 127 Therefore the button should not be shown, otherwise it mistakenly gives the impression that user could make it work by enabling screen-sharing permission which is not possible on mobile OS. opw-4108833 [1]: https://caniuse.com/mdn-api_mediadevices_getdisplaymedia <img width="333" alt="Screenshot 2024-08-21 at 13 26 13" src="https://github.com/user-attachments/assets/ead3281d-2ef4-412e-8d4f-edab4a85b1e9">
Miscellaneous changes
We did not catch checkout errors, which lead to server not restarting. Errors are now caught. Forward-Port-Of: odoo/odoo#177087
Original PR description
We did not catch checkout errors, which lead to server not restarting. Errors are now caught. Forward-Port-Of: odoo/odoo#177087
[IMP] l10n_{bf,bj,cd,ci,cm,ga,km,ml,ne,sn,tg}: make report definition more consistent - Doing if_above using EUR as the currency made no sense in those countries. We instead use the domestic currency (the result is equivalent, since 0 EUR = 0 in any other currency ; it's just clearer) - specifying rounding=2 on editable monetary value had no effect (on monetary values, the rounding is always made with the decimal places of the domestic currency), and was hence misleading.
Original PR description
[IMP] l10n_{bf,bj,cd,ci,cm,ga,km,ml,ne,sn,tg}: make report definition more consistent - Doing if_above using EUR as the currency made no sense in those countries. We instead use the domestic currency…
[IMP] l10n_{bf,bj,cd,ci,cm,ga,km,ml,ne,sn,tg}: make report definition more consistent
- Doing if_above using EUR as the currency made no sense in those countries. We instead use the domestic currency (the result is equivalent, since 0 EUR = 0 in any other currency ; it's just clearer)
- specifying rounding=2 on editable monetary value had no effect (on monetary values, the rounding is always made with the decimal places of the domestic currency), and was hence misleading.
----------------------------------------------------------
[IMP] account_reports: Enforce constraint on carryover target
We need to add constraints on the expression label and the carryover_target from account report so that we ensure that it is used correctly.
Currently, it may have happened that when we used the carryover mechanism, we were using the wrong label.
That could create some issues where the carryover would simply not work or partially.
----------------------------------------------------------
[FIX] l10n_bf: tax report: fix line name and formulas
- The report contained two lines numbered 26, while one of them had 27 in its code
- Line "Net VAT amount to pay"'s formula contained BF_OTHER_DEDUCTION twice
- Line "Credit VAT to report"'s formula contained BF_OTHER_DEDUCTION twice, and BF_CANCELLED (grid 25) was missing
We fix all those problems, and rewrite the formula of "Net VAT amount to pay" in order for it to better match the expression provided in the line name (for clarity).
-----------------------------------------------------------
[FIX] l10n_{bf, bj, cd, ci, cm, ga, km, ml, ne, sn, tg}: Fix Carryover for syscohada countries
For some syscohada countries some tax report where using carryover.
The carryover on the tax reports from these countries were not working.
The cause was one, the label of the expression used to target the applied carryover was not prefixed with _carryover_.
And two, is that it had no expression dedicated for carryover with label _applied_carryover and this was causing the report to miss the info tag on the line for the carryover.
task-4110461
Forward-Port-Of: odoo/odoo#177064
Forward-Port-Of: odoo/odoo#176489Following commit 380115da5ed346333512e63093a5cb3be217eeed a bug was introduced, preventing the user from claiming a discount reward if another reward was already claimed with the same coupon. Forward-Port-Of: odoo/odoo#176636
Original PR description
Following commit 380115da5ed346333512e63093a5cb3be217eeed a bug was introduced, preventing the user from claiming a discount reward if another reward was already claimed with the same coupon. Forward-Port-Of: odoo/odoo#176636
[FIX] website_blog: prevent "List" layout from overflowing on mobile Steps to reproduce: - Go to the "/blog" page. - In edit mode, set the "Layout" option to "List" and save. - Toggle the mobile preview or reduce the screen size at around 580px or below. => There is a horizontal scrollbar. The scrollbar appears because the row containing the blog posts has a bigger width than its container, which makes it overflow from it. It happens because of the `o_container_small` class set on
Original PR description
[FIX] website_blog: prevent "List" layout from overflowing on mobile Steps to reproduce: - Go to the "/blog" page. - In edit mode, set the "Layout" option to "List" and save. - Toggle the mobile…
[FIX] website_blog: prevent "List" layout from overflowing on mobile Steps to reproduce: - Go to the "/blog" page. - In edit mode, set the "Layout" option to "List" and save. - Toggle the mobile preview or reduce the screen size at around 580px or below. => There is a horizontal scrollbar. The scrollbar appears because the row containing the blog posts has a bigger width than its container, which makes it overflow from it. It happens because of the `o_container_small` class set on the container, which has a rule forcing its horizontal padding to 0, where it was supposed to compensate the row margins. This commit therefore fixes this issue by forcing the row horizontal margins to 0 for screen sizes under the `MD` screen breakpoint, which is approximately where the blogs layout becomes mobile. This fix also has the advantage of improving the "List" mobile layout by making it look similar to the "Grid" layout one, that is, with a bit of space around the posts, instead of being glued to the viewport. opw-4052853 --- [FIX] web_editor: prevent grid item inner row child from overflowing Steps to reproduce: - In edit mode, drop the "Team" snippet. - Toggle it to grid mode. - Set the "Content Width" option to "Full". => A horizontal scrollbar appears. This happens because the `.row` elements generally have a `--gutter-x` CSS variable set to 30px that is used to compute their horizontal margins, such that it compensates the padding of the parent (generally a `.container` element) which is set to the same value. So the parent is supposed to always have a padding of 15px, which is compensated by the row margins, set to -15px. When a row is a direct child of a grid item, the row can overflow its parent if the grid item has a padding below 15px. Indeed, the row expects its parent to have a 15px padding, so its margins are too big if the value is below. A horizontal scrollbar can therefore appear, if the snippet container takes the whole screen width. This commit fixes this issue by making the margins of row elements that are direct children of a grid item compensate the padding of this grid item, while it is below 15px. When it is set to 15px or above, they are back compensating the usual 15px. opw-4052853 opw-3981579 Forward-Port-Of: odoo/odoo#176975 Forward-Port-Of: odoo/odoo#176421
Extra checkout step was unable to be enabled because of a change (commit 533325a2) that was made to sync it with the active state of the extra info view. However, the view that was being checked was actually a view that did not exist. Correctly changed the view name to be extra_info instead of extra_info_option so the setting could be enabled. opw-4113506 Forward-Port-Of: odoo/odoo#176871
Original PR description
Extra checkout step was unable to be enabled because of a change (commit 533325a2) that was made to sync it with the active state of the extra info view. However, the view that was being checked was actually a view that did not exist. Correctly changed the view name to be extra_info instead of extra_info_option so the setting could be enabled. opw-4113506 Forward-Port-Of: odoo/odoo#176871
Instead of Odoo Point of Sale, the receipt is now showing Powered by Odoo. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#177081
Original PR description
Instead of Odoo Point of Sale, the receipt is now showing Powered by Odoo. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#177081
**Current behaviour before PR:** In table, empty single cell is not selectable through mouse. This happens because isVisible function fails to check if cell is empty or not. **Desired behaviour after PR:** Now it is possible to select empty cell through mouse. Now we are using isEmptyBlock to check if cell is empty or not. task-4067376 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#174663
Original PR description
**Current behaviour before PR:** In table, empty single cell is not selectable through mouse. This happens because isVisible function fails to check if cell is empty or not. **Desired behaviour after PR:** Now it is possible to select empty cell through mouse. Now we are using isEmptyBlock to check if cell is empty or not. task-4067376 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#174663
At the moment, JP is added at the start of the tax scheme vals. In Japan and after 2023-10-01, the expected value in the company_id is the "Registration Number for Qualified Invoice purpose in Japan" which starts with a T and does not want JP prepended to it. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#177144
Original PR description
At the moment, JP is added at the start of the tax scheme vals. In Japan and after 2023-10-01, the expected value in the company_id is the "Registration Number for Qualified Invoice purpose in Japan" which starts with a T and does not want JP prepended to it. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#177144
As mentioned in this [comment](https://github.com/odoo/odoo/pull/164295#issuecomment-2139764771), the `stardard_price` field in product was being recomputed even if this product had no negative layers to fix. Since standard_price is already recomputed before calling `_run_fifo_vacuum` (in `product_price_update_before_done`, for example), there's no need to recompute it again, especially with a different logic. Please refer to the comment I linked for more details. --- I confirm I have si
Original PR description
As mentioned in this [comment](https://github.com/odoo/odoo/pull/164295#issuecomment-2139764771), the `stardard_price` field in product was being recomputed even if this product had no negative layers to fix. Since standard_price is already recomputed before calling `_run_fifo_vacuum` (in `product_price_update_before_done`, for example), there's no need to recompute it again, especially with a different logic. Please refer to the comment I linked for more details. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#176924 Forward-Port-Of: odoo/odoo#167604
It is necessary to check access rights when linking a post to another forum, so that the user linked to the post always has access to it. task-4116016 Forward-Port-Of: odoo/odoo#176804 Forward-Port-Of: odoo/odoo#176744
Original PR description
It is necessary to check access rights when linking a post to another forum, so that the user linked to the post always has access to it. task-4116016 Forward-Port-Of: odoo/odoo#176804 Forward-Port-Of: odoo/odoo#176744
Fix query counters for event mail schedulers and mail template performance tests. Use warmup decorator to remove queries linked to cold state, in order to have results closer to real life scenario. Prepares Task-3084943: Event: Improve communication scheduler scalability Forward-Port-Of: odoo/odoo#177141 Forward-Port-Of: odoo/odoo#177099
Original PR description
Fix query counters for event mail schedulers and mail template performance tests. Use warmup decorator to remove queries linked to cold state, in order to have results closer to real life scenario. Prepares Task-3084943: Event: Improve communication scheduler scalability Forward-Port-Of: odoo/odoo#177141 Forward-Port-Of: odoo/odoo#177099
When a blog cover is edited, a tag option is displayed while there is no `tag_ids` inside the `blog.blog` model because the `o_wblog_post_page_cover` appears on both the `blog.blog` covers and on the `blog.post` covers. This commit hides the blog tags option if the model of the cover is `blog.blog`. Steps to reproduce: - Go to blogs. - Select the "Travel" blog. - Edit. - Select the blog's cover. => A tag option could be specified. opw-4107748 Forward-Port-Of: odoo/odoo#177077 Fo
Original PR description
When a blog cover is edited, a tag option is displayed while there is no `tag_ids` inside the `blog.blog` model because the `o_wblog_post_page_cover` appears on both the `blog.blog` covers and on the `blog.post` covers. This commit hides the blog tags option if the model of the cover is `blog.blog`. Steps to reproduce: - Go to blogs. - Select the "Travel" blog. - Edit. - Select the blog's cover. => A tag option could be specified. opw-4107748 Forward-Port-Of: odoo/odoo#177077 Forward-Port-Of: odoo/odoo#176510
Steps to reproduce the bug: - Create a storable product “P1” & “P2”, tracked by lot - Create a quant: - Product: “P1” - Lot: “Lot A” - Go to inventory adjustment, import a quant with: - Product: “P2” - Lot: “Lot A” Problem: A quant is created but linked with the record of “Lot A” of product “P1”, which is incorrect. An existing lot with product “P2” should be used, or a new one created if none is available. Unfortunately, in the ORM, the Load function performs a s
Original PR description
Steps to reproduce the bug:
- Create a storable product “P1” & “P2”, tracked by lot
- Create a quant:
- Product: “P1”
- Lot: “Lot A”
- Go to inventory adjustment, import a quant with:
- Product: “P2”
- Lot: “Lot A”
Problem:
A quant is created but linked with the record of “Lot A” of product
“P1”, which is incorrect. An existing lot with product “P2” should be
used, or a new one created if none is available. Unfortunately, in the
ORM, the Load function performs a simple name_search and takes the first
one founded, and it does not link the lot name with the related product.
opw-[4028709](https://www.odoo.com/web#id=4028709&view_type=form&model=project.task)
Forward-Port-Of: odoo/odoo#177179
Forward-Port-Of: odoo/odoo#173696__Current behavior before commit:__ When a mega menu has the class `o_mega_menu_container_size`, it is translated by 50% to the left because of this line [1]. However it shouldn't be if it is displayed inside a dropdown menu. __Description of the fix:__ Unset `transform` of `.o_mega_menu_container_size` when it is inside an `.o_extra_menu_items` element. __Steps to reproduce the issue on runbot:__ 1. Add a mega menu to the website 2. In the Editor, set Mega Menu > Size to `Narrow` a
Original PR description
__Current behavior before commit:__ When a mega menu has the class `o_mega_menu_container_size`, it is translated by 50% to the left because of this line [1]. However it shouldn't be if it is displayed inside a dropdown menu. __Description of the fix:__ Unset `transform` of `.o_mega_menu_container_size` when it is inside an `.o_extra_menu_items` element. __Steps to reproduce the issue on runbot:__ 1. Add a mega menu to the website 2. In the Editor, set Mega Menu > Size to `Narrow` and save 3. Resize the window just enough that a dropdown menu appear 4. Open the dropdown menu -> The mega menu is offset to the left opw-4021738 [1]: https://github.com/odoo/odoo/blob/9835632/addons/website/static/src/scss/website.scss#L1294 Forward-Port-Of: odoo/odoo#172438
**Current behavior:** If a production spawns some backorder which has available component quants in a package, the backorder will not have that quantity reserved automatically. **Expected behavior:** This available quantity should be reserved by rule (based on the manufacturing picking type's reservation configuration) automatically. **Steps to reproduce:** 1. Enable packages and 2-step manufacturing, use the default `at_confirm` option for the manufacturing method's `rese
Original PR description
**Current behavior:** If a production spawns some backorder which has available component quants in a package, the backorder will not have that quantity reserved automatically. **Expected behavior:**…
**Current behavior:**
If a production spawns some backorder which has available
component quants in a package, the backorder will not have that
quantity reserved automatically.
**Expected behavior:**
This available quantity should be reserved by rule (based on the
manufacturing picking type's reservation configuration)
automatically.
**Steps to reproduce:**
1. Enable packages and 2-step manufacturing, use the default
`at_confirm` option for the manufacturing method's
`reservation_method`
2. Create an MO for 10 of some storable product that has 10 of
some storable product as a component -> confirm the MO
3. In the generated pick operation for the MO, assign the 10
units of the storable product to the move's quantity
4. In barcode, open the picking and manually add 1 of the
components -> put it in a pack
5. Repeat step 3 an additional time
6. Validate the picking -> create the backorder
7. Open the initial manufacturing order in barcode
8. Consume one of the created packaged quants of the component,
ensuring to also add the +1 quantity to the final product
barcode line
9. Validate the MO -> create the backorder
10. In the backend, open the backorder to see that there is 0
quantity reserved
**Cause of the issue:**
In this scenario, the backorder's raw move does not gain any
availability until after the original order is marked done,
after which there is never any logic for the reservation to
occur.
**Fix:**
During the backorder generation and the mark done for the
original order, attempt to assign any backorder productions at
the instant when some component quantity becomes available.
opw-3989977
Forward-Port-Of: odoo/odoo#172955Currently `_run_fifo_vacuum` can be a performance bottleneck when confirming a large IN transfer. This is especially true for anglo_saxon accounting companies. To fix that, this commit introduces batch versions of `_run_fifo_vacuum` and `_create_fifo_vacuum_anglo_saxon_expense_entry`. The idea of these batch versions is to batch records creation, moves posting, search, etc. Stuff that cannot be batched/don't need to be batched are left as is. #### Speedup 15.0 customer database with 476 0
Original PR description
Currently `_run_fifo_vacuum` can be a performance bottleneck when confirming a large IN transfer. This is especially true for anglo_saxon accounting companies. To fix that, this commit introduces…
Currently `_run_fifo_vacuum` can be a performance bottleneck when confirming a large IN transfer. This is especially true for anglo_saxon accounting companies. To fix that, this commit introduces batch versions of `_run_fifo_vacuum` and `_create_fifo_vacuum_anglo_saxon_expense_entry`. The idea of these batch versions is to batch records creation, moves posting, search, etc. Stuff that cannot be batched/don't need to be batched are left as is. #### Speedup 15.0 customer database with 476 000 account.moves, 1M account.move.lines, 8400 products, 700 000 stock.moves, 650 000 stock.move.lines, 500 000 svls All categories have Inventory Valuation set to real_time. Benchmark validation of IN transfers, changing the number of products + total number of svls | Number of products | Total number of svls | Before PR | After PR | |:----------------:|:-------------------:|:-----------:|:-----------:| | 1 | 112 | 3.88s | 3.78s | | 2 | 607 | 548ms | 524ms | | 5 | 2561 | 2.27s | 1.10s | | 3 | 8956 | 15min | 2min | | 32 | 43310 | 7min | 50s | Some pickings are not directly impacted by the PR, most probably because these pickings don't have candidates svls/svls to vacuum to begin with. Still for the fourth and fith picking, the batch version performs way better than the iterative one. Validating an IN transfer with stock_account and real-time inventory valuation is a complex process so it's a bit difficult to pinpoint tables cardinalities that correlate with the validation time. Here it's the Before vs After time that is relevant, more than the validation time growth. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#170131 Forward-Port-Of: odoo/odoo#157558
Description of the issue/feature this PR addresses: When change date_planned field of a confirmed PO, some times can happen if there more than one line_section or line_note, these lines is seen as product_lines. Current behavior before PR: Before Assertion failure for round digits for precision digits on method https://github.com/odoo/odoo/blob/16.0/odoo/tools/float_utils.py#L25 So we can't change the date_planned values. Desired behavior after PR is merged: I can change the date_pl
Original PR description
Description of the issue/feature this PR addresses: When change date_planned field of a confirmed PO, some times can happen if there more than one line_section or line_note, these lines is seen as product_lines. Current behavior before PR: Before Assertion failure for round digits for precision digits on method https://github.com/odoo/odoo/blob/16.0/odoo/tools/float_utils.py#L25 So we can't change the date_planned values. Desired behavior after PR is merged: I can change the date_planned field More Note: I see the problem for version 14.0 15.0 e and 16.0 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#168676
When using a non parsable ODOO_MAX_HTTP_THREADS value, take into account max_cron_threads. When a lot of xmlrpc or jsonrpc calls are made, 2 cursor are used per call due to the authentification so it maxes out and the pool limit. If the cron_thread are using a cursor we end up with a "Pool Is Full" error. Forward-Port-Of: odoo/odoo#172902
Original PR description
When using a non parsable ODOO_MAX_HTTP_THREADS value, take into account max_cron_threads. When a lot of xmlrpc or jsonrpc calls are made, 2 cursor are used per call due to the authentification so it maxes out and the pool limit. If the cron_thread are using a cursor we end up with a "Pool Is Full" error. Forward-Port-Of: odoo/odoo#172902
Adding a condition in _get_stock_account_property_field_names to avoid recomputing the property_stock_account_production_cost_id value. task-id: 3646156 enterprise: https://github.com/odoo/enterprise/pull/65904/ --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#171616
Original PR description
Adding a condition in _get_stock_account_property_field_names to avoid recomputing the property_stock_account_production_cost_id value. task-id: 3646156 enterprise: https://github.com/odoo/enterprise/pull/65904/ --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#171616
In this commit (https://github.com/odoo/odoo/commit/464090d8da5e7bc59a3afe4764b9235022ee75cd), we made the container for product images and media elements responsive. However, multiple clients did not appreciate the changes and like the images being highlighted. Additionally it was not the main focus of the ticket. opw-4056701 Forward-Port-Of: odoo/odoo#176034
Original PR description
In this commit (https://github.com/odoo/odoo/commit/464090d8da5e7bc59a3afe4764b9235022ee75cd), we made the container for product images and media elements responsive. However, multiple clients did not appreciate the changes and like the images being highlighted. Additionally it was not the main focus of the ticket. opw-4056701 Forward-Port-Of: odoo/odoo#176034
### Description of the issue/feature this PR addresses: Ensure that credit and debit notes in the Uruguayan localization select the correct document type based on the originating document. This update ensures alignment with regulatory requirements: electronic invoices, electronic tickets, export invoices, electronic boletas, and non-electronic documents each dictate the corresponding document type for credit and debit notes created from them ### Steps to reproduce: 1. Install l10n_uy mo
Original PR description
### Description of the issue/feature this PR addresses: Ensure that credit and debit notes in the Uruguayan localization select the correct document type based on the originating document. This…
### Description of the issue/feature this PR addresses: Ensure that credit and debit notes in the Uruguayan localization select the correct document type based on the originating document. This update ensures alignment with regulatory requirements: electronic invoices, electronic tickets, export invoices, electronic boletas, and non-electronic documents each dictate the corresponding document type for credit and debit notes created from them ### Steps to reproduce: 1. Install l10n_uy module 2. Create and validate an invoice of tyoe "(121) Export e-Invoice"  3. Create Credit Note clicking the button on the invoice form.  ### Current behavior before PR: 1. The new Credit Note document type suggested is `(0) Credit None` (a different type of the original invoice) 2. Also the domain show all the document types of type Credit, so the user can select a wrong document  ### Desired behavior after PR is merged: 1. The new credit Note document type will match the original invocie 2. The domain will be restricted to the possible credit note subtypes  --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#173979
Current behavior: When a cashier enter a payment value with more precision than the rounding precision (eg. rounding=0.10 and payment value=1.25), he just cannot proceed to the payment. Steps to reproduce: - Install "Point of Sale" app - Go to the settings and enable the cash rounding - Go the shop settings and enable the cash rounding and create a down rounding method with a precision of 0.10 - Start a shop session, select a product and go to the payment screen - Select a payment metho
Original PR description
Current behavior: When a cashier enter a payment value with more precision than the rounding precision (eg. rounding=0.10 and payment value=1.25), he just cannot proceed to the payment. Steps to…
Current behavior: When a cashier enter a payment value with more precision than the rounding precision (eg. rounding=0.10 and payment value=1.25), he just cannot proceed to the payment. Steps to reproduce: - Install "Point of Sale" app - Go to the settings and enable the cash rounding - Go the shop settings and enable the cash rounding and create a down rounding method with a precision of 0.10 - Start a shop session, select a product and go to the payment screen - Select a payment method and write a number on the numpad so that the value goes up to the cent (eg. 1.25) - Select another payment method to pay the rest Solution: With this commit, an error popup will be displayed explaining why the cashier cannot proceed the payment and what he could change to authorize the payment. This popup should appear when selecting another payment method and when validating the payment. opw-3992018 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#176673 Forward-Port-Of: odoo/odoo#174145
After this commit, the following stat buttons from the project updates panel have been fixed: - Vendor Bills: Add the possibility to create new vendor bills from the stat button and link the new vendor bill to the AA of the current project. Also fix the "Upload" button (no more error "The journal in which to upload the invoice is not specified"). - Invoices: Same as for Vendor Bills (link the AA to the newly created invoice). - Manufacturing Orders: Same fix as above. - Expenses (access vi
Original PR description
After this commit, the following stat buttons from the project updates panel have been fixed: - Vendor Bills: Add the possibility to create new vendor bills from the stat button and link the new vendor bill to the AA of the current project. Also fix the "Upload" button (no more error "The journal in which to upload the invoice is not specified"). - Invoices: Same as for Vendor Bills (link the AA to the newly created invoice). - Manufacturing Orders: Same fix as above. - Expenses (access via the "Expenses" link from the profitability table): Same fix as above. - Sales Orders: Before this commit, we could only create new SOs from the project form view stat button, we can now do it from the stat button of the project updates panel. And again, same fix as above for the AA. version-17.0 task-3973206 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#171476
This fix add a verification check to ir.filter and ir.default. This aims at preventing user to put such record out of their own reach This behaviour is usually valid in Odoo, however in this case, it is not normal that the user cannot delete the filter and default that he created himself. Forward-Port-Of: odoo/odoo#176740 Forward-Port-Of: odoo/odoo#174227
Original PR description
This fix add a verification check to ir.filter and ir.default. This aims at preventing user to put such record out of their own reach This behaviour is usually valid in Odoo, however in this case, it is not normal that the user cannot delete the filter and default that he created himself. Forward-Port-Of: odoo/odoo#176740 Forward-Port-Of: odoo/odoo#174227
Steps to reproduce: /!\ on mobile - Sale > Any Product > Sales tab - Add an optional product - Website > Shop > Select product - Add to cart Columns are misaligned with their data, the style that dictates which elements should display depending on screen width only applied to the table body, meaning we had 4 columns with only three data points to fill them, hence why everything is shifted over to the left. opw-4067850 --- I confirm I have signed the CLA and read the PR guidelines
Original PR description
Steps to reproduce: /!\ on mobile - Sale > Any Product > Sales tab - Add an optional product - Website > Shop > Select product - Add to cart Columns are misaligned with their data, the style that dictates which elements should display depending on screen width only applied to the table body, meaning we had 4 columns with only three data points to fill them, hence why everything is shifted over to the left. opw-4067850 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#175350
Steps to reproduce =================== 1. Install website_sale module 2. Go to any campaign in marketing_automation 3. The kanban card of the activity will have buttons misplaced in the title Issue ================= With commit https://github.com/odoo/odoo/pull/165486/commits/f46e7e8bd6dc205d83a107f62d8b5944caa3d4d5, a style was applied for website_sale form mobile view. The selector also matched marketing_automation's campaign form view which removed the required float property from th
Original PR description
Steps to reproduce =================== 1. Install website_sale module 2. Go to any campaign in marketing_automation 3. The kanban card of the activity will have buttons misplaced in the title Issue ================= With commit https://github.com/odoo/odoo/pull/165486/commits/f46e7e8bd6dc205d83a107f62d8b5944caa3d4d5, a style was applied for website_sale form mobile view. The selector also matched marketing_automation's campaign form view which removed the required float property from the element. After this commit ================= This commit makes the selector in website_sale more specific to match only the desired element. Task-4110902 Forward-Port-Of: odoo/odoo#176920
13 changes
Enhancements to existing features
The WhatsApp Point of Sale receipt screen has been redesigned to make sending receipts by email or phone clearer and easier for cashiers. This improves the checkout experience with a more polished, user-friendly layout.
Original PR description
### Before <img width="859" alt="Screenshot 2024-08-21 at 10 24 50 AM" src="https://github.com/user-attachments/assets/3441b646-f032-4075-8583-b5b1c500cd9d"> ### After <img width="859" alt="Screenshot 2024-08-21 at 9 50 29 AM" src="https://github.com/user-attachments/assets/12025f2c-5f06-4e49-829d-02c5fddc9624">
HR teams can now manage appraisal templates as reusable records and select them in company settings, departments, and appraisal forms. This makes appraisal setup more consistent, easier to maintain, and ready to use with default templates included.
Original PR description
This PR introduces improvements to the HR appraisal template functionality. - Addition of the hr_appraisal_template model. - Inclusion of default appraisal templates in the data. - Replacement of templates with Many2one fields in the app settings and department, linking to the new model. - Addition of Many2one fields in the appraisal form view. - Provision of access rights for the new model. task-3895915
Resolved issues and error corrections
This fix ensures customer-facing text in the UrbanPiper point-of-sale order information popup can be translated properly. It helps businesses provide a more consistent localized experience for users working in different languages.
Original PR description
This commit fixes the props that pass strings to use `.translate` introduced in: [#174697](https://github.com/odoo/odoo/pull/174697) Community: https://github.com/odoo/odoo/pull/175568
Products created or updated from the Barcode Lookup service now use the first returned image as the main product image and show the remaining images in the online shop. This helps shoppers see more complete product visuals and reduces missing or incomplete product presentation.
Original PR description
This commit ensure the first image get from Barcode Lookup API is defined as the product image and all the next ones are displayed on the web shop.
Features or functions removed from Odoo
This update removes hardcoded banner or onboarding elements across consolidation, reporting, signing, and website sales dashboard areas. It helps keep the user experience cleaner and easier to maintain without changing core business workflows.
Code cleanup and technical improvements
The WhatsApp module was internally adjusted to return simpler record references where possible. This supports cleaner data handling and helps keep related WhatsApp functionality easier to maintain without changing the user experience.
Original PR description
Enterprise counter-part. Part of task-3605717 https://github.com/odoo/odoo/pull/176918
Miscellaneous changes
During aea506700d9a3253c02f46f587a3e360a89cce0b, we forgot to adapt the model that was inheriting `account.generic.tax.report.handler` to make it inherit the new `account.tax.report.handler` model. Because of that, we never passed into the `_get_vat_closing_entry_additional_domain` method, leading to wrong lines being included in the closing entry. Steps: - Install l10n_lu and l10n_eu_oss_reports - Create and confirm two invoices, one with tax 17% S and the other with tax 20.0% FR VAT - Go t
Original PR description
During aea506700d9a3253c02f46f587a3e360a89cce0b, we forgot to adapt the model that was inheriting `account.generic.tax.report.handler` to make it inherit the new `account.tax.report.handler` model. Because of that, we never passed into the `_get_vat_closing_entry_additional_domain` method, leading to wrong lines being included in the closing entry. Steps: - Install l10n_lu and l10n_eu_oss_reports - Create and confirm two invoices, one with tax 17% S and the other with tax 20.0% FR VAT - Go to LU Tax Report, select the same month as the invoices - Click on Closing Entry button -> There are lines from tax 20.0% FR VAT, they should not be there opw-4015752 Forward-Port-Of: odoo/enterprise#67815
Before this commit: Generating return label on delivery was disabled intentionally. After this commit: Option to select return label on delivery is enabled. A warning is added in `sendcloud_product_selection_widget` for customers befroe selecting return product. opw-4008265 Forward-Port-Of: odoo/enterprise#68447
Original PR description
Before this commit: Generating return label on delivery was disabled intentionally. After this commit: Option to select return label on delivery is enabled. A warning is added in `sendcloud_product_selection_widget` for customers befroe selecting return product. opw-4008265 Forward-Port-Of: odoo/enterprise#68447
Steps: 1) Install website_helpdesk_forum 2) Create a Helpdesk Team with a forum connected to it 3) Open the post on that forum and click on the "Create Ticket" 4) The team selection field is empty Cause: The data of the teams are not coming correctly via the route Fix: In the route, we will only send the team connected to the forum. This issue was discovered while creating a test case for this task. Task-4034550 Forward-Port-Of: odoo/enterprise#66827
Original PR description
Steps: 1) Install website_helpdesk_forum 2) Create a Helpdesk Team with a forum connected to it 3) Open the post on that forum and click on the "Create Ticket" 4) The team selection field is empty Cause: The data of the teams are not coming correctly via the route Fix: In the route, we will only send the team connected to the forum. This issue was discovered while creating a test case for this task. Task-4034550 Forward-Port-Of: odoo/enterprise#66827
- 17.0 <hr> - Currently, the tour is written according to the demo data. The selector .o_form_sheet div[name] input will match if the work template is 'Device Installation and Maintenance' . This template is available in the demo. If the demo loads, the default 'Device Installation and Maintenance' will be set via the post hook. When the demo does not load, we will have the default template instead. That's why we used the .o_form_sheet p.oe-command-temporary-hint class in the OR condit
Original PR description
- 17.0 <hr> - Currently, the tour is written according to the demo data. The selector .o_form_sheet div[name] input will match if the work template is 'Device Installation and Maintenance' . This template is available in the demo. If the demo loads, the default 'Device Installation and Maintenance' will be set via the post hook. When the demo does not load, we will have the default template instead. That's why we used the .o_form_sheet p.oe-command-temporary-hint class in the OR condition. - Remove import `loaded_demo_data` from industry_fsm tests because it was not in use from this [commit](https://github.com/odoo/enterprise/commit/90ca61c62ecb0e5ddcf4d1e1ec9e0a2bf27c27f1). task-4086026 Forward-Port-Of: odoo/enterprise#68517 Forward-Port-Of: odoo/enterprise#67846
Two warnings need to be conditionally hidden if the company does not have an OSCU active: - the warning on invoices that the delivered quantities do not match invoiced quantities; and - the warning on BoMs. In addition, we take the opportunity to remove the method `env['product.product']._compute_l10n_ke_validation_message` which is dead code. Forward-Port-Of: odoo/enterprise#68474 Forward-Port-Of: odoo/enterprise#68423
Original PR description
Two warnings need to be conditionally hidden if the company does not have an OSCU active: - the warning on invoices that the delivered quantities do not match invoiced quantities; and - the warning on BoMs. In addition, we take the opportunity to remove the method `env['product.product']._compute_l10n_ke_validation_message` which is dead code. Forward-Port-Of: odoo/enterprise#68474 Forward-Port-Of: odoo/enterprise#68423
In the case where the HR responsible is not required to sign, he should not be added to the request items. Forward-Port-Of: odoo/enterprise#68622
Original PR description
In the case where the HR responsible is not required to sign, he should not be added to the request items. Forward-Port-Of: odoo/enterprise#68622
Before this commit when opening a report that take fiscal year as the period_type, the display in the date dropdown was wrong. task: 4096212 Forward-Port-Of: odoo/enterprise#67960
Original PR description
Before this commit when opening a report that take fiscal year as the period_type, the display in the date dropdown was wrong. task: 4096212 Forward-Port-Of: odoo/enterprise#67960
8 changes
Resolved issues and error corrections
This update fixes a display issue in the Sign module where signature frames would be partially hidden when the signature box had an unusual aspect ratio (very wide or very short). The fix restores the proper container styling to ensure the signature frame and its hash remain fully visible regardless of the box dimensions.
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
This update adds support for the FedEx International Connect Plus shipping service type, which was previously missing from the available delivery options. This enables businesses using Odoo's FedEx integration to offer this international shipping method to their customers, expanding their delivery service capabilities.
Original PR description
before this commit: Service type `FEDEX_INTERNATIONAL_CONNECT_PLUS` was not available the list 'fedex_service_type'. After this commit: Missing service type is added in the list. reference fedex doc: https://developer.fedex.com/api/en-us/guides/api-reference.html#servicetypes opw-4061797 Forward-Port-Of: odoo/enterprise#64250
This update removes the display of empty IS (insurance) lines in Swiss payroll processing. The change improves the clarity of payroll documents by eliminating unnecessary blank entries, making payroll statements cleaner and easier to read for employees and administrators.
Knowledge templates were not displaying correctly when exported or printed due to broken styling. This fix restores proper formatting and layout to ensure templates appear as intended when users export or print them. This improves the quality and usability of exported knowledge documents.
Original PR description
**Before this PR:** The style of some knowledge templates was broken when attempting to export or print, lacking proper formatting as per the templated structure. It seemed like there was an issue with the template's responsiveness. **After this PR:** Now, the issue has been addressed, and now the template is appropriately formatted and styled, ensuring correctness during export. **Task**-3664950
This update adjusts the Chart of Accounts report test in the Mexico localization module to account for a newly added account (173.01 Deferred expenses). The change ensures that the trial balance test continues to work correctly with the expanded chart of accounts structure.
Original PR description
Purpose of this PR: CoA Report trial balance test adjusted to accommodate for the new account, 173.01 Deferred expenses Community PR that adds new account: #176681 opw-4105993
Portal users who have access to a shared task but not the entire project can now properly view task documents. Previously, clicking the document button would redirect them back to the home menu because it tried to access project-level documents they weren't authorized to view. The fix ensures the button only appears when users have the appropriate access rights.
Original PR description
Steps to reproduce: - Create a project and a task - Attach a file to the task - Share the task with Joel Willis (portal user) - DO NOT share the project with him - Log in as Joel Willis (portal user) - Click Tasks > '1 Document' button next to project name This redirects back to portal home menu. This happens because the button leads to projects/id/documents, which Joel Willis has not been granted access to. The expectation would be a redirection to tasks/id/documents instead, as portal > projects handles this use case, and we curently do not have a way to share documents attached to a specific task through portal. opw-4009258
This fix resolves access errors that occurred when branch users tried to perform common tasks like creating products or accessing currency information. The solution adds a new permission rule allowing branch users to read their parent company's data, which is necessary for these operations to work correctly without granting excessive permissions.
Original PR description
This PR tries to solve 2 bugs related to branches: one from 17.4 and one from 17.0. Community PR: https://github.com/odoo/odoo/pull/176502 ### Steps to reproduce (in saas-17.4): - Add a branch to the…
This PR tries to solve 2 bugs related to branches: one from 17.4 and one from 17.0.
Community PR: https://github.com/odoo/odoo/pull/176502
### Steps to reproduce (in saas-17.4):
- Add a branch to the current company
- Create another user that only have the branch as "Allowed Companies"
- Give this user the right to create `product.template` for example by assigning him as administrator in Inventory or POS
- Switch to this user
- Go in Inventory > Products > Products
- Click on the "New" button
- An access error should pop up
### Steps to reproduce (in 17.0):
- Add a branch to the current company
- Create another user that only have the branch as "Allowed Companies"
- Switch to this user
- Go in Purchase app and create a new RFQ
- Click on the internal link of "Currency"
- An access error should pop up
### Cause:
- saas-17.4: When trying to find the tax values for the product, Odoo tries to read the values of `res.company.account_fiscal_country_id` and an error is raised.
- 17.0: To access the currency of the company, the user must have read access on the company.
### Solution:
Create a new rule that permits the branches to read the record of the parent company. Changing the rule "company rule employee" domain to `[('id','parent_of', company_ids)]` also works but it is giving a lot more rights to branches.
This change required changing performance tests.
opw-4088233This update fixes an issue where articles exported or printed from the Knowledge editor would have content cut off or display blank pages. The fix removes height constraints on article containers and disables scroll views during printing, allowing content to flow naturally across pages without clipping. Additional styling adjustments hide elements that shouldn't appear in printed documents.
Original PR description
Currently, when the user prints an article using the "export" button from the Knowledge editor, it happens that the page can be clipped. This commit will fix that issue by (1) unsetting the height constraints set on the containers of the article and by (2) de-activating the scroll views for the printing devices. The containers should now have a natural height and each block should follow the natural flow of the document which prevents clipping. This commit will also apply other minor CSS adjustments to hide elements that should not be printed. task-3664950