Monday, August 1, 2022
37 changes · master
Enhancements to existing features
Guest users' chat availability status is now shown in the messaging interface instead of only being stored in the background. This makes conversations clearer by helping users see whether a guest participant is online or available.
Original PR description
Before this PR, the `im_status` for guest was stored, but not displayed. task-2883466
Watch mode for automated tours now gets a much longer default timeout, reducing interruptions while teams investigate slow or failing tests. The watch mode status is also shared with the browser client, enabling future improvements to debugging behavior.
Original PR description
Currently, when enabling watch mode on a tour the tour's timeout does not change. This is usually an issue because: - watch mode makes tours a bit slower, so they can timeout even without doing anything - trying to diagnose what's wrong, it's common to add check steps with a long timeout or even a `debugger` statement, which trips the python-side timeout and kills the tour To avoid needing to remember to update the timeouts (then revert them afterwards), just bump the timeout to 1h by default, or 10x the original time for very long tours (e.g. qweb test suite, which currently has a 30mn timeout). While at it, forward the watch mode status to the client via the QS, so we can eventually make use of it for one reason or an other.
This update removes unnecessary internal code from the website delivery checkout flow. It keeps delivery behavior the same while reducing maintenance risk for future changes.
Original PR description
**Description of the issue/feature this PR addresses:** Just some code cleanup. There's no need to set carrier_id to False. This is already taken care by `delivery` module since 448312173. Also avoid overwriting docstring on overridden method. @pimodoo -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The HR work permit upload field has been updated to use Odoo's newer interface framework. This helps keep the employee document upload experience current and easier to maintain, with no major change expected for day-to-day users.
Original PR description
This commit rewrites WorkPermitUploadField using the new framework.
The event module’s icon selector has been rebuilt on Odoo’s newer interface framework. This helps keep the feature maintainable and consistent with the rest of the platform, with minimal expected change for end users.
Original PR description
This commit rewrites IconSelectorField using the new framework.
The live chat window setup has been simplified by removing older configuration code. This helps keep the live chat feature easier to maintain without changing the customer-facing chat experience.
Original PR description
Task-2937190
Live chat now uses a dedicated public message data structure to better manage messages shown to website visitors. This improves the foundation for a smoother and more reliable chat experience without changing core business workflows.
Original PR description
Task-2937196
The live chat experience now handles the chatbot welcome message timing through the live chat button view. This makes the greeting behavior more consistent and easier to manage, helping visitors receive chat prompts at the right moment.
Original PR description
Task-2937917
Unused live chat code was removed from the system. This simplifies the product behind the scenes, making future maintenance easier without changing the customer-facing live chat experience.
Original PR description
Task-2937959
This update removes redundant or overly technical help text from many Odoo screens and improves the remaining guidance. It reduces translation workload, avoids sending unnecessary text to the interface, and makes future tooltips more focused and useful for users.
Original PR description
[IMP] cleanup of help messages in all modules
This commit aims at removing unuseful help message to:
1/ reduce translators work, to focus on more useful translations
2/ not sending unuseful information in load_views
3/ reduce help message to useful messages, so that we can mark
fields having a tooltip in the future UI.
4/ some cleanup of existing messages too
The main use cases:
- REMOVED: help redundant with the field name, providing no extra info
- MOVED TO COMMENT: technical help messages, that should not be in UX
- IMPROVED help messages
--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prResolved issues and error corrections
Fixes a crash that occurred when users tried to reschedule a meeting activity after opening the calendar from a contact. This keeps the contact activity workflow smooth and avoids interruptions when updating meeting schedules.
Original PR description
In a contact form view, schedule an activity (from the chatter), select type Meeting, and click on the "Open Calendar" button. In the calendar view, create a new event. Then, go back to the contact form view. The activity should be there, and it should display a "Reschedule" button. Before this commit, it crashed when we clicked on that button. The reason is that the click handler calls a python method that returns an action description (action from xmlid, with modified context). However, this action was sent back to the client without being "cleaned", which is what the client expects. In particular, the 'tree' view type is unknown client side, it must be renamed into 'list'. This commit fixes the issue by cleaning the action before sending it back. 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
Features or functions removed from Odoo
This change removes the separate website-specific UTM component because the main website module already includes the needed UTM support. It also moves tracking response updates to a more reliable stage so cookies or headers can be applied consistently, including error or fallback pages.
Original PR description
`_post_dispatch` is a late addition to the httpocalypse. It can be used to alter the response object e.g. to inject headers or cookies. The function is automatically called for regular, fallback and error responses. On the other hand, `_dispatch` is only called when an endpoint is matched and might not return a response in case of error. Task: 2839031 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
Code cleanup and technical improvements
The mail and live chat code now uses one direct method for adding records instead of routing through an extra internal step. This reduces complexity for developers and helps keep future maintenance simpler without changing the user experience.
Original PR description
The way the code has evolved, `create` is now no more than an unnecessary indirection for `insert`. This PR removes `create` and replaces its uses with `insert` directly.
Miscellaneous changes
This commit fixes following html block [1] ``` xml <div class="fc-content"> <span class="fc-time">08:00</span> <div class="o_event_title">Mitchel Admin - Administrator</div> </div> ``` `rtlcss` lib changes `padding-right` to `padding-left`, which doesn't work if we use `span` block next to `div` block, because position of the blocks are not changed (time is still on the left side and title is on the right). Adding the `ignore` directive solves the issue.
Original PR description
This commit fixes following html block [1]
``` xml
<div class="fc-content">
<span class="fc-time">08:00</span>
<div class="o_event_title">Mitchel Admin - Administrator</div>
</div>
```
`rtlcss` lib changes `padding-right` to `padding-left`, which doesn't work if we
use `span` block next to `div` block, because position of the blocks are not
changed (time is still on the left side and title is on the right). Adding the
`ignore` directive solves the issue.
[1]: https://github.com/odoo/odoo/blob/4a996060e6b922fecb299eca32d6763dbb12b831/addons/web/static/src/legacy/xml/web_calendar.xml#L16-L17
opw-2925491
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#97060List views now handle buttons that are hidden for certain users or conditions without triggering an error. This improves reliability for users working with views that include permission-based or conditional actions.
Original PR description
Before this commit, an error was raised when an invisible button was found on a list view (for example, if it has a group). Now, the invisible buttons are correctly managed.
This fixes a web data loading issue so the requested fields are now properly used when retrieving records. It helps ensure users and integrations receive the expected information instead of unnecessary or incorrect data.
Original PR description
Description of the issue/feature this PR addresses: Load the correct fields in then /web/dataset/load. Current behavior before PR: The argument fields is not used. Desired behavior after PR is merged: The argument fields is used. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The web interface ribbon widget was converted to a cleaner internal structure while keeping the same behavior for users. This makes the code easier to maintain and align with other interface components, reducing future development effort without changing day-to-day workflows.
The public live chat experience is being reorganized to use the same modern structure as Odoo Discuss. This helps make future improvements easier and more consistent, with little expected immediate change for end users.
Original PR description
*: website_livechat This commit is a step towards refactoring the JS of public livechat, so that it reuses the same architecture as the code of Discuss. This implies code that uses JS models and OWL components. Task-2939083
Step to reproduce: - Create variants for product without grid - Go to website - Try to add variant of created product to wishlist Current behaviour: - Product ID is not properly fetched - Product template is added to wishlist Behaviour after PR: - Product ID is properly fetched - Product is added to wishlist opw-2705883 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#95529 Forward-Port-Of: odoo/odoo#85599
Original PR description
Step to reproduce: - Create variants for product without grid - Go to website - Try to add variant of created product to wishlist Current behaviour: - Product ID is not properly fetched - Product template is added to wishlist Behaviour after PR: - Product ID is properly fetched - Product is added to wishlist opw-2705883 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#95529 Forward-Port-Of: odoo/odoo#85599
Steps to reproduce: 1- install sale, accounting 2- create a fiscal position fp that maps tax inc t1 to any other tax t2 3- create a delivery product dp with t1 and mark it "can be sold" 4- create a new delivery method with dp 5- in a new sales order, choose fp, click on add delivery 6- the unit_price is wrong, it hasn't mapped t1 to t2 7- try adding the delivery as a product in a new sales order line 8- the unit_price is correct and the taxes are correctly calculated Bug: `_cre
Original PR description
Steps to reproduce: 1- install sale, accounting 2- create a fiscal position fp that maps tax inc t1 to any other tax t2 3- create a delivery product dp with t1 and mark it "can be sold" 4- create a…
Steps to reproduce: 1- install sale, accounting 2- create a fiscal position fp that maps tax inc t1 to any other tax t2 3- create a delivery product dp with t1 and mark it "can be sold" 4- create a new delivery method with dp 5- in a new sales order, choose fp, click on add delivery 6- the unit_price is wrong, it hasn't mapped t1 to t2 7- try adding the delivery as a product in a new sales order line 8- the unit_price is correct and the taxes are correctly calculated Bug: `_create_delivery_line` is not using the same logic used when normally adding a sales order line although technically delivery product is still a product Fix: remove the tax handling from `_create_delivery_line` and use `product_id_change` onchange method to handle calculations in the same streamlined way OPW-2806965 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#96169 Forward-Port-Of: odoo/odoo#92263
Description of the issue/feature this PR addresses: Click 'My Tasks' menu in Project Current behavior before PR: Traceback occurred Desired behavior after PR is merged: No Traceback -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#96844 Forward-Port-Of: odoo/odoo#96576
Original PR description
Description of the issue/feature this PR addresses: Click 'My Tasks' menu in Project Current behavior before PR: Traceback occurred Desired behavior after PR is merged: No Traceback -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#96844 Forward-Port-Of: odoo/odoo#96576
We keep the statement line note when changing the partner in reconciliation widget Steps: - Create a Bank Statement, a Bank Statement Line BSL with a note (field narration) - Open the reconciliation widget, change/set the partner and go back to statement. -> The note on BSL is empty With this commit we allow narration computation only for sale documents. opw-2832287 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior aft
Original PR description
We keep the statement line note when changing the partner in reconciliation widget Steps: - Create a Bank Statement, a Bank Statement Line BSL with a note (field narration) - Open the reconciliation widget, change/set the partner and go back to statement. -> The note on BSL is empty With this commit we allow narration computation only for sale documents. opw-2832287 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#97068 Forward-Port-Of: odoo/odoo#92845
…m or cancel popup The "pressing a specific key to confirm/cancel a popup" behavior was added but the problem was that some popups only had one button which was either confirm or cancel. It was thus possible to close those popups by bypassing the default behavior (e.g. possible to "cancel" a popup which only has one button linked to an overridden confirm method and vice-versa). Also, we normalize the use of `confirm` and `cancel` methods in the popups so that when the specifics keys are p
Original PR description
…m or cancel popup The "pressing a specific key to confirm/cancel a popup" behavior was added but the problem was that some popups only had one button which was either confirm or cancel. It was thus possible to close those popups by bypassing the default behavior (e.g. possible to "cancel" a popup which only has one button linked to an overridden confirm method and vice-versa). Also, we normalize the use of `confirm` and `cancel` methods in the popups so that when the specifics keys are pressed, the right behavior is executed. Forward-Port-Of: odoo/odoo#96824
Setting transformations on images is handled by the jQuery transfo plugin. This plugin, however, also manipulates animation related css (notably `animation-play-state` and `transition`) properties allowing the plugin to work on animated images. After closing the transformation tools these properties stay in the DOM, preventing the animation options to work properly. Animations are not played when previewing or selecting a choice from the dropdown list. Instead they remain stuck in their initi
Original PR description
Setting transformations on images is handled by the jQuery transfo plugin. This plugin, however, also manipulates animation related css (notably `animation-play-state` and `transition`) properties allowing the plugin to work on animated images. After closing the transformation tools these properties stay in the DOM, preventing the animation options to work properly. Animations are not played when previewing or selecting a choice from the dropdown list. Instead they remain stuck in their initial keyframe. To avoid complications from the interaction between both options, this commit hides either option when the other is activated. Additionally, css properties added by the transform option are cleaned, avoiding potential interactions after the transform option is reset again. opw-2765529 Forward-Port-Of: odoo/odoo#97107 Forward-Port-Of: odoo/odoo#87339
Just fixing a typo in `_render_qweb_pdf_prepare_streams()`. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#97166
Original PR description
Just fixing a typo in `_render_qweb_pdf_prepare_streams()`. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#97166
When getting the on hand quantity of a product in a specific location, the result may be incorrect. To reproduce the issue: 1. In Settings, enable "Storage Locations" 2. Create a storable product P 3. Update its quantity: - 5 x P at WH/Stock/Shelf 1 4. Inventory > Reporting > Inventory Report 5. Apply the following filters: - Product: P - Location: WH/Stock/Shelf 1 - => There is a line with 5 x P at WH/Stock/Shelf 1, which is correct 6. Click on Inventory at Date,
Original PR description
When getting the on hand quantity of a product in a specific location, the result may be incorrect. To reproduce the issue: 1. In Settings, enable "Storage Locations" 2. Create a storable product P…
When getting the on hand quantity of a product in a specific location,
the result may be incorrect.
To reproduce the issue:
1. In Settings, enable "Storage Locations"
2. Create a storable product P
3. Update its quantity:
- 5 x P at WH/Stock/Shelf 1
4. Inventory > Reporting > Inventory Report
5. Apply the following filters:
- Product: P
- Location: WH/Stock/Shelf 1
- => There is a line with 5 x P at WH/Stock/Shelf 1, which is
correct
6. Click on Inventory at Date, set \<Today\>, confirm
7. Apply the following filters:
- Product: P
- Location: WH/Stock/Shelf 1
Error: There is a line for P but its on hand quantity is 0, which is
incorrect (should be 5)
In the first search, we let the ORM handle the domain conversion. When
searching for `('location_id', 'ilike', 'WH/Stock/Shelf 1')`, it will
use the `_rec_name` of the model to find the record. In case of a stock
location, its `_rec_name` is the field `complete_name`:
https://github.com/odoo/odoo/blob/94a8ad3fae914b046064bb7ce17572be8280f6e0/addons/stock/models/stock_location.py#L19
However, for the second search, when getting the on-hand quantity of the
product, we force the use of the field `name` to find the location.
Because the `name` of the searched location is "Shelf 1", using
"WH/Stock/Shelf 1" as key search will not work.
OPW-2920904
Forward-Port-Of: odoo/odoo#96827Steps to reproduce: - Install eCommerce with product comparator - Open the product in </shop> - Change the product quantity - Click on the <Enter> key Current behavior: En error message appears. Expected behavior: No error message appears. Explanation: The productComparison widget overrided the submit with a selector that was not specific to the comparison so its _onFormSubmit function could be called from other pages creating errors. To solve the issue we add a specific class
Original PR description
Steps to reproduce: - Install eCommerce with product comparator - Open the product in </shop> - Change the product quantity - Click on the <Enter> key Current behavior: En error message appears. Expected behavior: No error message appears. Explanation: The productComparison widget overrided the submit with a selector that was not specific to the comparison so its _onFormSubmit function could be called from other pages creating errors. To solve the issue we add a specific class to the form and to the selector. opw-2936994 Forward-Port-Of: odoo/odoo#97074
Steps to reproduce the bug: - Create a storable product - Archive it - Try to print labels Problem: A traceback is triggered, Because when we click on print the label we have to open the wizard, so we load the wizard model `product.label.layout` via an onchange: https://github.com/odoo/odoo/blob/15.0/odoo/models.py#L6357-L6360 thanks to the context, it will find the concerned product (via default_product_id) Except that the product is archived, so ignored in the result returned by t
Original PR description
Steps to reproduce the bug: - Create a storable product - Archive it - Try to print labels Problem: A traceback is triggered, Because when we click on print the label we have to open the wizard, so…
Steps to reproduce the bug: - Create a storable product - Archive it - Try to print labels Problem: A traceback is triggered, Because when we click on print the label we have to open the wizard, so we load the wizard model `product.label.layout` via an onchange: https://github.com/odoo/odoo/blob/15.0/odoo/models.py#L6357-L6360 thanks to the context, it will find the concerned product (via default_product_id) Except that the product is archived, so ignored in the result returned by the onchange Therefore, in the confirmation, we will create the wizard, but it will not have a product filled, so in the `_prepare_report_data` function we do not enter in the if or the elif: https://github.com/odoo/odoo/blob/d9f45ba6941939b3d4b40beb5abbc330be84d695/addons/product/wizard/product_label_layout.py#L49-L54 it will therefore raise a traceback when we want to iterate on it: https://github.com/odoo/odoo/blob/d9f45ba6941939b3d4b40beb5abbc330be84d695/addons/product/wizard/product_label_layout.py#L60 opw-2855659 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#96798
Open Accounting>Journal Items Select 1+ items with 0 credit/debit Hit Actions>Automatic Entries In the wizard choose 'Change Period', select an Accrued Account with 'reconcile' flag and confirm Error will raise 'You are trying to reconcile some entries that are already reconciled.' It is not clear to the user, but the issue is that lines with 0 balance are considered as reconciled. New entries, with 0 balance, will be created to match the selected one, but on reconciliation the issue
Original PR description
Open Accounting>Journal Items Select 1+ items with 0 credit/debit Hit Actions>Automatic Entries In the wizard choose 'Change Period', select an Accrued Account with 'reconcile' flag and confirm Error will raise 'You are trying to reconcile some entries that are already reconciled.' It is not clear to the user, but the issue is that lines with 0 balance are considered as reconciled. New entries, with 0 balance, will be created to match the selected one, but on reconciliation the issue will raise opw-2909058 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#96733
When printing an invoice, the customer address was not displayed if there was no delivery address specified. As the address should be displayed at the same place than when the delivery address and customer address are the same, we just paste the code from the related condition. opw-2899259 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
Original PR description
When printing an invoice, the customer address was not displayed if there was no delivery address specified. As the address should be displayed at the same place than when the delivery address and customer address are the same, we just paste the code from the related condition. opw-2899259 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#97190 Forward-Port-Of: odoo/odoo#95867
The below line raises a KeyError when `warehouse` refers to an archived warehouse. https://github.com/odoo/odoo/blob/01cc43b0578ecc9d1fed37a12b2468ffc9d4aedd/addons/stock/models/stock_orderpoint.py#L396 The reason is that the SQL view created on https://github.com/odoo/odoo/blob/01cc43b0578ecc9d1fed37a12b2468ffc9d4aedd/addons/stock/report/report_stock_quantity.py#L28-L37 doesn't take into account whether the warehouses are archived or not. The solution proposed here is to fetch all war
Original PR description
The below line raises a KeyError when `warehouse` refers to an archived warehouse. https://github.com/odoo/odoo/blob/01cc43b0578ecc9d1fed37a12b2468ffc9d4aedd/addons/stock/models/stock_orderpoint.py#L396 The reason is that the SQL view created on https://github.com/odoo/odoo/blob/01cc43b0578ecc9d1fed37a12b2468ffc9d4aedd/addons/stock/report/report_stock_quantity.py#L28-L37 doesn't take into account whether the warehouses are archived or not. The solution proposed here is to fetch all warehouses to ensure the lookup doesn't fail. Alternatively the view could be updated but that will be a bigger change. This issue was detected during the upgrade 226754 Forward-Port-Of: odoo/odoo#88204
Before this fix, there were two issues: 1. The 'Current Year Earnings' line from the BS was incorrect. 2. The date range on the P&L when redirected from the BS was wrong. It was due to the way the options were set when coming from a 'single' to 'range' mode. The date_from was not set to the beginning of the company's fiscal year, which generated unintended values. task-2895748 Forward-Port-Of: odoo/enterprise#29882
Original PR description
Before this fix, there were two issues: 1. The 'Current Year Earnings' line from the BS was incorrect. 2. The date range on the P&L when redirected from the BS was wrong. It was due to the way the options were set when coming from a 'single' to 'range' mode. The date_from was not set to the beginning of the company's fiscal year, which generated unintended values. task-2895748 Forward-Port-Of: odoo/enterprise#29882
**Current behavior before PR:** When opening any form view in the studio, reloading the view raises an evaluation error like 'active_id' is not defined. **Desired behavior after PR is merged:** No traceback is being generated. Task-2803270 Forward-Port-Of: odoo/enterprise#27968 Forward-Port-Of: odoo/enterprise#27022
Original PR description
**Current behavior before PR:** When opening any form view in the studio, reloading the view raises an evaluation error like 'active_id' is not defined. **Desired behavior after PR is merged:** No traceback is being generated. Task-2803270 Forward-Port-Of: odoo/enterprise#27968 Forward-Port-Of: odoo/enterprise#27022
The "pressing a specific key to confirm/cancel a popup" behavior was added but the problem was that some popups only had one button which was either confirm or cancel. It was thus possible to close those popups by bypassing the default behavior (e.g. possible to "cancel" a popup which only has one button linked to an overridden confirm method and vice-versa). Forward-Port-Of: odoo/enterprise#29859
Original PR description
The "pressing a specific key to confirm/cancel a popup" behavior was added but the problem was that some popups only had one button which was either confirm or cancel. It was thus possible to close those popups by bypassing the default behavior (e.g. possible to "cancel" a popup which only has one button linked to an overridden confirm method and vice-versa). Forward-Port-Of: odoo/enterprise#29859
The Swiss QR-bills are now supported. When a QR-bill is found, the content will be used to create a new partner or fill the fields of an existing partner. The other fields will be filled by as usual, but using the data extracted from the QR-bill. Task : 2906388 Forward-Port-Of: odoo/enterprise#29206
Original PR description
The Swiss QR-bills are now supported. When a QR-bill is found, the content will be used to create a new partner or fill the fields of an existing partner. The other fields will be filled by as usual, but using the data extracted from the QR-bill. Task : 2906388 Forward-Port-Of: odoo/enterprise#29206
Steps to reproduce the bug: - Create a SO: - select any storable product - save - Click on add shipping - Select DHL - Click on "Gate rate" Problem: a Traceback is triggered, because the `rate_shipment_vals` function calls the DHL api which returns an error message with the code `410304`, but the function does not catch this error code, so does not go into the if and returns nothing: https://github.com/odoo/enterprise/blob/524bbf4b2ce83908d6bb5f8011a679f6aec441fc/delivery_
Original PR description
Steps to reproduce the bug: - Create a SO: - select any storable product - save - Click on add shipping - Select DHL - Click on "Gate rate" Problem: a Traceback is triggered, because the…
Steps to reproduce the bug:
- Create a SO:
- select any storable product
- save
- Click on add shipping
- Select DHL
- Click on "Gate rate"
Problem:
a Traceback is triggered, because the `rate_shipment_vals` function
calls the DHL api which returns an error message with the code `410304`,
but the function does not catch this error code, so does not go into
the if and returns nothing:
https://github.com/odoo/enterprise/blob/524bbf4b2ce83908d6bb5f8011a679f6aec441fc/delivery_dhl/models/delivery_dhl.py#L163-L169
Therefore, when the result is processed the object is null
-> a traceback is triggered:
https://github.com/odoo/odoo/blob/980d103050fee552a9f68421cf119c119397bbe2/addons/delivery/models/delivery_carrier.py#L174
The DHL API returns an error, because the package is too big, this is
due to the demo data, we use 409 x 444 x 541 mm, but due to a bug in
odoo, this unit of measure(mm) does not matter, because regardless
of the uom used when encoding a package, the data sent to the shipper
will be the one defined in the shipping method (cm in our case). We must
therefore adapt the demo dates temporarily to avoid this error in runbot
opw-2926634
opw-2908089
Forward-Port-Of: odoo/enterprise#29883The report line 'Legal capital reserves' of the Swiss balance sheet contains P&L accounts Steps to reproduce: 1. Install module l10n_ch_reports 2. Open Accounting and create a customer invoice with a product and an invoice date in the previous year 3. Save and confirm the invoice 4. Go to Accounting > Reporting > Switzerland > Balance Sheet 5. The line 'Legal capital reserves' is unfoldable and shows P&L accounts which is not correct Solution: Show accounts 29XX in a new lin
Original PR description
The report line 'Legal capital reserves' of the Swiss balance sheet contains P&L accounts Steps to reproduce: 1. Install module l10n_ch_reports 2. Open Accounting and create a customer invoice with a product and an invoice date in the previous year 3. Save and confirm the invoice 4. Go to Accounting > Reporting > Switzerland > Balance Sheet 5. The line 'Legal capital reserves' is unfoldable and shows P&L accounts which is not correct Solution: Show accounts 29XX in a new line and add Annual profits or anual loss to another line that doesn't show the accounts Add an action on the P&L line in balance sheet that opens up the P&L report opw-2894965 Forward-Port-Of: odoo/enterprise#29954 Forward-Port-Of: odoo/enterprise#28910