Daily updates from Odoo
Wednesday, August 21, 2024
5 changes · saas-17.4
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