Wednesday, November 20, 2024
17 changes · saas-17.4
Resolved issues and error corrections
Requests for Quotation using the DIN 5008 document layout now include the same key information as purchase order PDFs. This prevents missing details when vendors receive RFQ documents and keeps purchasing documents consistent.
Original PR description
### Steps to reproduce the issue: 1. In the Document Layout, choose DIN 5008 as Layout 2. Create a Request for Quotation 3. In the extra menu (cog wheel), select Print > Purchase Order 4. In the extra menu (cog wheel), select Print > Request for Quotation 5. When comparing both templates, some informations are missing in the Request for Quotation PDF ### Explanation: An override adding those informations is implemented for `report_purchaseorder_document` but not for `report_purchasequotation_document`. ### Fix reasoning: Adding a similar override for the latter will fix the issue. opw-4337273
Miscellaneous changes
Forward-Port-Of: odoo/odoo#187620 Forward-Port-Of: odoo/odoo#185343
Original PR description
Forward-Port-Of: odoo/odoo#187620 Forward-Port-Of: odoo/odoo#185343
When our own bank is used as a payment means, it shouldn't be populated in the OIOUBL XML. When using Peppol, the XML would ignore the endpoint that is set in the electronic invoicing settings, the <cbc:EndpointID> should be the defined Peppol endpoint and the schemeID should be 'GLN'. task-4017019 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#171945
Original PR description
When our own bank is used as a payment means, it shouldn't be populated in the OIOUBL XML. When using Peppol, the XML would ignore the endpoint that is set in the electronic invoicing settings, the <cbc:EndpointID> should be the defined Peppol endpoint and the schemeID should be 'GLN'. task-4017019 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#171945
When confirming a BILL via Project's Updates, the generated payment terms line will have the analytic account of the project assigned Version: 17.0+ Steps to reproduce: - Have a project (i.e. Renovations) - Create a Purchase Order - Add on the line the analytic account of the project - Go to Projects Kanban view - Open Project 3 dots menu > Reporting > Project Updates - Open the created PO, Create Bill Issue: Analytic account will be assigned to the payment term line opw-4193509
Original PR description
When confirming a BILL via Project's Updates, the generated payment terms line will have the analytic account of the project assigned Version: 17.0+ Steps to reproduce: - Have a project (i.e. Renovations) - Create a Purchase Order - Add on the line the analytic account of the project - Go to Projects Kanban view - Open Project 3 dots menu > Reporting > Project Updates - Open the created PO, Create Bill Issue: Analytic account will be assigned to the payment term line opw-4193509 Forward-Port-Of: odoo/odoo#187612
Steps to reproduce: - Calendar > New > Tick 'Recurrent' - 'Until' => 'Number of repetitions' or 'Forever' - Set meeting start time in 5 mins - Add reminder => Notification - 15 Minutes > Save The notification is not sent, this is due to the use of 'until' to fetch the last event date of recurrent meetings despite that field only being set if the recrrence type is 'End date'. We want to check that date to avoid sending notifications for past meetings, but 'Number of Repetitions' recursions
Original PR description
Steps to reproduce: - Calendar > New > Tick 'Recurrent' - 'Until' => 'Number of repetitions' or 'Forever' - Set meeting start time in 5 mins - Add reminder => Notification - 15 Minutes > Save The notification is not sent, this is due to the use of 'until' to fetch the last event date of recurrent meetings despite that field only being set if the recrrence type is 'End date'. We want to check that date to avoid sending notifications for past meetings, but 'Number of Repetitions' recursions use a count instead of a date, and 'Forever' obviously doesn't need a date. Using the meeting end date instead should do the trick since it will always be in the future at the moment we want to send the reminder and it should never go over the last event date since no meeting record will be created after the recurrence ends anyway. opw-4247282 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#187423
Steps to reproduce: 1.Add an any image block ( here Text - Image ) 2.Add the URL on the image 3.Now edit the image and add the video to it; you will notice that the URL remains as it is in the toolbar 4.Click on Save Issue: For versions 15.0-16.0, the link and URL both remain. For version 17.0-Master, the video element gets removed unexpectedly. Expected Behavior: When a video is inserted, the URL should be automatically removed to avoid element removal or loss of responsiveness.
Original PR description
Steps to reproduce: 1.Add an any image block ( here Text - Image ) 2.Add the URL on the image 3.Now edit the image and add the video to it; you will notice that the URL remains as it is in the toolbar 4.Click on Save Issue: For versions 15.0-16.0, the link and URL both remain. For version 17.0-Master, the video element gets removed unexpectedly. Expected Behavior: When a video is inserted, the URL should be automatically removed to avoid element removal or loss of responsiveness. Issue: The issue of element getting removed or loss of responsiveness is because we did not remove the url link when we inserted the video. Solution: This PR resolves the issue by removing the URL link when a video is inserted in place of an image, ensuring the video element is retained and options are hidden appropriately. task-4023555 Forward-Port-Of: odoo/odoo#186642 Forward-Port-Of: odoo/odoo#172390
**Steps to reproduce:** - Create a PDF report for the stock.picking model - Use the template stock.label_transfer_template_view_pdf. - When saving the report, the mentioned error occurred. ```py odoo.addons.base.models.ir_qweb.QWebException: Error while render the template AttributeError: 'stock.picking' object has no attribute 'move_lines' Template: stock.label_transfer_template_view_pdf Path: /t/t/div/t[2]/t[2] Node: <t t-foreach="picking.move_ids" t-as="move"/> ``` - [Ref](https:
Original PR description
**Steps to reproduce:** - Create a PDF report for the stock.picking model - Use the template stock.label_transfer_template_view_pdf. - When saving the report, the mentioned error occurred. ```py…
**Steps to reproduce:** - Create a PDF report for the stock.picking model - Use the template stock.label_transfer_template_view_pdf. - When saving the report, the mentioned error occurred. ```py odoo.addons.base.models.ir_qweb.QWebException: Error while render the template AttributeError: 'stock.picking' object has no attribute 'move_lines' Template: stock.label_transfer_template_view_pdf Path: /t/t/div/t[2]/t[2] Node: <t t-foreach="picking.move_ids" t-as="move"/> ``` - [Ref](https://github.com/odoo/odoo/pull/78732) were move_lines has been renamed to move_ids. - [Ref](https://github.com/odoo/odoo/pull/80434) were product_uom_qty has been renamed to reserved_uom_qty. **Desired behavior after PR is merged:** - Can create a report for stock.picking model  OPW - [4239654](https://www.odoo.com/odoo/project/70/tasks/4239654) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#187427 Forward-Port-Of: odoo/odoo#184046
step to reproduce: 1. create a db in 16.0 with appointment and account_payment module 2. create ``User-defined default`` (ir_default): Settings -> Technical -> User-defined Defaults - Field = Unit of Measure (product.template) - Default Value (JSON format) = 3 (pick any id that is not in the same category as `uom.product_uom_unit`) 2. upgrade db to 17.0 version below mentioned traceback will raised because appointment_account_payment is auto install. ``` Traceback (most recent call last):
Original PR description
step to reproduce: 1. create a db in 16.0 with appointment and account_payment module 2. create ``User-defined default`` (ir_default): Settings -> Technical -> User-defined Defaults - Field = Unit of…
step to reproduce:
1. create a db in 16.0 with appointment and account_payment module
2. create ``User-defined default`` (ir_default): Settings -> Technical -> User-defined Defaults
- Field = Unit of Measure (product.template)
- Default Value (JSON format) = 3 (pick any id that is not in the same category as `uom.product_uom_unit`)
2. upgrade db to 17.0 version below mentioned traceback will raised because appointment_account_payment is auto install.
```
Traceback (most recent call last):
File "/home/odoo/src/odoo/17.0/odoo/service/server.py", line 1313, in preload_registries
registry = Registry.new(dbname, update_module=update_module)
File "<decorator-gen-16>", line 2, in new
File "/home/odoo/src/odoo/17.0/odoo/tools/func.py", line 87, in locked
return func(inst, *args, **kwargs)
File "/home/odoo/src/odoo/17.0/odoo/modules/registry.py", line 114, in new
odoo.modules.load_modules(registry, force_demo, status, update_module)
File "/home/odoo/src/odoo/17.0/odoo/modules/loading.py", line 480, in load_modules
processed_modules += load_marked_modules(env, graph,
File "/home/odoo/src/odoo/17.0/odoo/modules/loading.py", line 364, in load_marked_modules
loaded, processed = load_module_graph(
File "/home/odoo/src/odoo/17.0/odoo/modules/loading.py", line 227, in load_module_graph
load_data(env, idref, mode, kind='data', package=package)
File "/home/odoo/src/odoo/17.0/odoo/modules/loading.py", line 71, in load_data
tools.convert_file(env, package.name, filename, idref, mode, noupdate, kind)
File "/home/odoo/src/odoo/17.0/odoo/tools/convert.py", line 627, in convert_file
convert_xml_import(env, module, fp, idref, mode, noupdate)
File "/home/odoo/src/odoo/17.0/odoo/tools/convert.py", line 693, in convert_xml_import
obj.parse(doc.getroot())
File "/home/odoo/src/odoo/17.0/odoo/tools/convert.py", line 613, in parse
self._tag_root(de)
File "/home/odoo/src/odoo/17.0/odoo/tools/convert.py", line 556, in _tag_root
f(rec)
File "/home/odoo/src/odoo/17.0/odoo/tools/convert.py", line 567, in _tag_root
raise ParseError(msg) from None # Restart with "--log-handler odoo.tools.convert:DEBUG" for complete traceback
odoo.tools.convert.ParseError: while parsing /home/odoo/src/enterprise/17.0/appointment_account_payment/data/product_data.xml:8
The default Unit of Measure and the purchase Unit of Measure must be in the same category.
View error context:
'-no context-'
```
why this traceback is raised because here in default values of [``uom_po_id``](https://github.com/odoo/odoo/blob/834e8a8789d1d451f62ae1e841845baf7d3931a4/addons/product/models/product_template.py#L36) getting default value of uom_id due to that other catefory uom_id is coming and [validation](https://github.com/odoo/odoo/blob/834e8a8789d1d451f62ae1e841845baf7d3931a4/addons/product/models/product_template.py#L456)
error raised and db got blocked
opw-4313919
upg-2182151
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#187663This PR fixes an issue about the pager buttons having a wrong `border-radius` in RTL languages. Prior to this PR, the icons were defined at the button level. On top of being unusual, this had a side-effect. In RTL languages, we use a CSS `transform: rotate(180deg);` on our directional icons,in order to flip their direction and match the RTL or LTR. While this works totally fine, having the icon sets on the button directly means the whole button will be flipped, meaning the border-radius wi
Original PR description
This PR fixes an issue about the pager buttons having a wrong `border-radius` in RTL languages. Prior to this PR, the icons were defined at the button level. On top of being unusual, this had a…
This PR fixes an issue about the pager buttons having a wrong `border-radius` in RTL languages. Prior to this PR, the icons were defined at the button level. On top of being unusual, this had a side-effect. In RTL languages, we use a CSS `transform: rotate(180deg);` on our directional icons,in order to flip their direction and match the RTL or LTR. While this works totally fine, having the icon sets on the button directly means the whole button will be flipped, meaning the border-radius will be inverted. To prevent this behaviour, we simply need to use a `<i/>` tag for both icons, which will allow them to be flipped without affecting the button design. | 17.0 | This PR | |--------|--------| | <img width="159" alt="image" src="https://github.com/user-attachments/assets/2afc13b3-0b4b-4baf-a306-2196a3c83867"> | <img width="159" alt="image" src="https://github.com/user-attachments/assets/a405e167-6a0f-4a49-a15d-4e36735d95f5"> | task-4345233 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#187741
Steps to reproduce: - Install Accounting > Settings > Enable 'Analytic Accounting' - Project App > New > Project Settings > Edit Analytic plan - Change Plan from 'Projects' to any other (except Internal) - Manufacturing > Operations > Manufacturing Orders > New - Product: 'Table Top' - Miscellaneous tab > Analytic distribution: <Project account> - Confirm > Produce All > Set quantities & Validate - Project > ':' Menu > Project Updates (Dashboard in 18.0+) - The cost of materials ($160)
Original PR description
Steps to reproduce: - Install Accounting > Settings > Enable 'Analytic Accounting' - Project App > New > Project Settings > Edit Analytic plan - Change Plan from 'Projects' to any other (except…
Steps to reproduce: - Install Accounting > Settings > Enable 'Analytic Accounting' - Project App > New > Project Settings > Edit Analytic plan - Change Plan from 'Projects' to any other (except Internal) - Manufacturing > Operations > Manufacturing Orders > New - Product: 'Table Top' - Miscellaneous tab > Analytic distribution: <Project account> - Confirm > Produce All > Set quantities & Validate - Project > ':' Menu > Project Updates (Dashboard in 18.0+) - The cost of materials ($160) is not deducted in Project costs Analytic distributions include different categories for each plan, this is reflected in DB with a different column for each plan, account_id/x_plan2_id/x_plan3_id/... which contain the project's analytic account. In version 18.0 and above we allow each project to have several analytic accounts (for the project, department, ...) but prior to that we relied on plan_id to differentiate the project account category. When checking for analytic lines to populate the project updates we check the `account_id`, meaning only lines with projects having analytic plan 'Projects' would pass that filter domain. We instead want to grab the account_id from any of the plan columns. opw-4282092 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#187275
### Steps to reproduce: - Create 2 storable products: Final product (FP) and Component (COMP) - Put 10 units of COMP in stock - Create a Bill of Material for FP: - raw move: 10 x COMP - 1 operation: "Register COMP" - Add an instruction on your operation: - type: "Register consumed component" - Product To Register: COMP - Create and confirm an MO for 1 Unit of FP - Go to the shopfloor > "Register COMP" - Change the quantity to 3 > Validate #### > Go back to the MO the
Original PR description
### Steps to reproduce: - Create 2 storable products: Final product (FP) and Component (COMP) - Put 10 units of COMP in stock - Create a Bill of Material for FP: - raw move: 10 x COMP - 1 operation:…
### Steps to reproduce:
- Create 2 storable products: Final product (FP) and Component (COMP)
- Put 10 units of COMP in stock
- Create a Bill of Material for FP:
- raw move: 10 x COMP
- 1 operation: "Register COMP"
- Add an instruction on your operation:
- type: "Register consumed component"
- Product To Register: COMP
- Create and confirm an MO for 1 Unit of FP
- Go to the shopfloor > "Register COMP"
- Change the quantity to 3 > Validate
#### > Go back to the MO the quantity of the raw move is still 10
### Cause of the issue:
Clicking on "Validate" as well as on "Continue consumption" will trigger a call of the `_next` method with `continue_production=False` and `True` respectively:
https://github.com/odoo/enterprise/blob/e86b97f57e2388b3b65326cecedd3c14ca02ddb1/mrp_workorder/models/quality.py#L346-L352 However, if you underconsume, a new move line will be created for the remaining quantity in both cases and it should only when you `Continue consumption`.
### Note:
If you underconsume, and change the quantity of the raw move without changing its original demand. As such, its state will itself change. Hence, if you come back to the MO, the reservation sate of the MO will be recomputed and be updated from assigned to confirmed. However, as the raw move is picked it should not alter the reservation state of the MO anymore:
https://github.com/odoo/odoo/blob/9918e8f3d627f3c52238d6b04bcd15c05d34e40c/addons/mrp/models/mrp_production.py#L613 This is the purpose of the community PR.
opw-4216910
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#186782
Forward-Port-Of: odoo/odoo#186475Forward-Port-Of: odoo/enterprise#74024 Forward-Port-Of: odoo/enterprise#72823
Original PR description
Forward-Port-Of: odoo/enterprise#74024 Forward-Port-Of: odoo/enterprise#72823
This PR aims to increase the contrast between the default and the `focus` state of our `btn-primary`. | 17.0 | This PR | |--------|--------| | <img width="729" alt="image" src="https://github.com/user-attachments/assets/19c29432-4467-46bf-b240-41017d435c09"> | <img width="717" alt="image" src="https://github.com/user-attachments/assets/1efc15cc-6e10-460b-9040-4088cf3a98e0"> | Prior to this PR, the color was not dark enough to grant enough visual feedback on focus. This can be solve quic
Original PR description
This PR aims to increase the contrast between the default and the `focus` state of our `btn-primary`. | 17.0 | This PR | |--------|--------| | <img width="729" alt="image" src="https://github.com/user-attachments/assets/19c29432-4467-46bf-b240-41017d435c09"> | <img width="717" alt="image" src="https://github.com/user-attachments/assets/1efc15cc-6e10-460b-9040-4088cf3a98e0"> | Prior to this PR, the color was not dark enough to grant enough visual feedback on focus. This can be solve quickly by tweaking the value directly. task-3382308 Forward-Port-Of: odoo/enterprise#71793
Before this commit contact created from amazon order create new state if it does not find matching state in odoo and it was causing issues like having record multiple record for same state and user don't know which one is right with proper code in data. This commit stop creating new state instead create activity on contact for amazon sale person to set proper state on the related contact to not break flows that are related to contact's state. Backport of b327ea1897fca34164a9bbea59a23d34b97
Original PR description
Before this commit contact created from amazon order create new state if it does not find matching state in odoo and it was causing issues like having record multiple record for same state and user don't know which one is right with proper code in data. This commit stop creating new state instead create activity on contact for amazon sale person to set proper state on the related contact to not break flows that are related to contact's state. Backport of b327ea1897fca34164a9bbea59a23d34b97e65a2 task-3865454 Forward-Port-Of: odoo/enterprise#74099
## [FIX] l10n_be_reports: 281.50 and exchange diff The aim of this commit is to prevent a Zero devision error by excluding irrelevant 'zeroed' exchange difference. Context: Some misc entry with a 0 balance and some amount_currency might be present and taken into account for the computation. Such moves have an `amount_total_signed` equal to 0 leading to the zeroDivisionError issue in the query computation. Before the commit: When having such entry considered by the query, creating th
Original PR description
## [FIX] l10n_be_reports: 281.50 and exchange diff The aim of this commit is to prevent a Zero devision error by excluding irrelevant 'zeroed' exchange difference. Context: Some misc entry with a 0 balance and some amount_currency might be present and taken into account for the computation. Such moves have an `amount_total_signed` equal to 0 leading to the zeroDivisionError issue in the query computation. Before the commit: When having such entry considered by the query, creating the 325.50 form leads to a traceback. After the commit: Those irrelevant moves are ignored and the process carry on smoothly. task-id: None - Issue spotted on next ## [FIX] l10n_be_reports: 281.50, no 0-0-0-0-0 form The aim of this commit is to avoid generating a 281.50 form if there isn't any amounts to fill in the form. task-id: None - Dicussed with TSB Forward-Port-Of: odoo/enterprise#73842
**Steps to reproduce the bug:** - Create a tracked product by SN: “P1.” - Create a storable product: "P2." - Create a receipt for one unit of P1 and P2. - Mark it as "To Do." - Set the done quantity of P1 to 0. - Attempt to perform the quality check. **Problem:** You must perform a quality check for P1 even though it has yet to be received. Since the move_line is set to 0 rather than deleted in the original picking, it will be linked to the backorder when it is created. Therefore,
Original PR description
**Steps to reproduce the bug:** - Create a tracked product by SN: “P1.” - Create a storable product: "P2." - Create a receipt for one unit of P1 and P2. - Mark it as "To Do." - Set the done quantity of P1 to 0. - Attempt to perform the quality check. **Problem:** You must perform a quality check for P1 even though it has yet to be received. Since the move_line is set to 0 rather than deleted in the original picking, it will be linked to the backorder when it is created. Therefore, to avoid unexpected behavior we can ignore linking its quality check to the backorder. https://github.com/odoo/odoo/blob/00057f8efd3c728e13a981290a725878e058d2c6/addons/stock/models/stock_picking.py#L832 opw-4187521 Forward-Port-Of: odoo/enterprise#73407
### Steps to reproduce: - Create 2 storable products: Final product (FP) and Component (COMP) - Put 10 units of COMP in stock - Create a Bill of Material for FP: - raw move: 10 x COMP - 1 operation: "Register COMP" - Add an instruction on your operation: - type: "Register consumed component" - Product To Register: COMP - Create and confirm an MO for 1 Unit of FP - Go to the shopfloor > "Register COMP" - Change the quantity to 3 > Validate #### > Go back to the MO the
Original PR description
### Steps to reproduce: - Create 2 storable products: Final product (FP) and Component (COMP) - Put 10 units of COMP in stock - Create a Bill of Material for FP: - raw move: 10 x COMP - 1 operation:…
### Steps to reproduce:
- Create 2 storable products: Final product (FP) and Component (COMP)
- Put 10 units of COMP in stock
- Create a Bill of Material for FP:
- raw move: 10 x COMP
- 1 operation: "Register COMP"
- Add an instruction on your operation:
- type: "Register consumed component"
- Product To Register: COMP
- Create and confirm an MO for 1 Unit of FP
- Go to the shopfloor > "Register COMP"
- Change the quantity to 3 > Validate
#### > Go back to the MO the quantity of the raw move is still 10
### Cause of the issue:
Clicking on "Validate" as well as on "Continue consumption" will trigger a call of the `_next` method with `continue_production=False` and `True` respectively:
https://github.com/odoo/enterprise/blob/e86b97f57e2388b3b65326cecedd3c14ca02ddb1/mrp_workorder/models/quality.py#L346-L352 However, if you underconsume, a new move ine will be created for the remaining quantity in both cases and it should only when you `Continue consumption`.
### Note:
If you underconsume, and change the quantity of the raw move without changing its original demand. As such, its state will itself change. Hence, if you come back to the MO, the reservation sate of the MO will be recomputed and be updated from assigned to confirmed. However, as the raw move is picked it should not alter the reservation state of the MO anymore:
https://github.com/odoo/odoo/blob/9918e8f3d627f3c52238d6b04bcd15c05d34e40c/addons/mrp/models/mrp_production.py#L613 This is the purpose of the community PR.
opw-4216910
Forward-Port-Of: odoo/enterprise#73577
Forward-Port-Of: odoo/enterprise#73396