Wednesday, August 21, 2024
42 changes · saas-17.2
Resolved issues and error corrections
The consolidated balance report no longer crashes when users change the unit currency display, such as selecting values in thousands. This makes the consolidation workflow more reliable without changing existing report behavior.
Original PR description
Steps to reproduce: - open consolidation - Select one of the consolidation - Smart button > Consolidated balance - Change the unit currency and put e.g. `In K€` Issue: Keyerror Cause: When opening the consolidated balance, the line does not take into account all the keys ghenerally present in other reports https://github.com/odoo/enterprise/blob/saas-17.2/account_consolidation/report/builder/abstract.py#L272-L278 Solution: Using get to be more defensive. No change is made in the consolidation module as it will be deperecated in 18.0. opw-4089130
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)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
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
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
As per section 34(2) of CGST Act 2017, credit notes for invoices from the financial year cannot be included in GSTR after November 30th. With this PR, if a credit note is created after November 30th of the financial year, an alert will be displayed to remind users to exclude the tax, as it cannot be included in GSTR. POT file also added for `l10n_in_gstr_reports` **task**-3915664 Forward-Port-Of: odoo/enterprise#68644 Forward-Port-Of: odoo/enterprise#66713
Original PR description
As per section 34(2) of CGST Act 2017, credit notes for invoices from the financial year cannot be included in GSTR after November 30th. With this PR, if a credit note is created after November 30th of the financial year, an alert will be displayed to remind users to exclude the tax, as it cannot be included in GSTR. POT file also added for `l10n_in_gstr_reports` **task**-3915664 Forward-Port-Of: odoo/enterprise#68644 Forward-Port-Of: odoo/enterprise#66713
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
"Colony code" translation changed from: "Código postal" => "Código de colonia" Forward-Port-Of: odoo/enterprise#68600 Forward-Port-Of: odoo/enterprise#68566
Original PR description
"Colony code" translation changed from: "Código postal" => "Código de colonia" Forward-Port-Of: odoo/enterprise#68600 Forward-Port-Of: odoo/enterprise#68566
Part of a UI task. Changed CONTINUE/PAUSE to CONTINUE/START Regenerated the PDF file task-id: 3646156 community: https://github.com/odoo/odoo/pull/171616 Forward-Port-Of: odoo/enterprise#65904
Original PR description
Part of a UI task. Changed CONTINUE/PAUSE to CONTINUE/START Regenerated the PDF file task-id: 3646156 community: https://github.com/odoo/odoo/pull/171616 Forward-Port-Of: odoo/enterprise#65904
### Steps to reproduce the issue: 1. Create a Batch of Payments 2. Create a Bank Statement Line and reconcile it with one of the Payments in the Batch 3. Go on any other Bank Statement Line and go to the Batch section 4. The amount shown on the line of the batch did not change ### Explanation: If a Batch is partially reconciled with Bank Statement Lines, `_compute_from_payment_ids_`, which would recalculate `amount_residual`, is not called. ### Fix reasoning: `is_matched` updat
Original PR description
### Steps to reproduce the issue: 1. Create a Batch of Payments 2. Create a Bank Statement Line and reconcile it with one of the Payments in the Batch 3. Go on any other Bank Statement Line and go to the Batch section 4. The amount shown on the line of the batch did not change ### Explanation: If a Batch is partially reconciled with Bank Statement Lines, `_compute_from_payment_ids_`, which would recalculate `amount_residual`, is not called. ### Fix reasoning: `is_matched` updates on every reconciliation between a Bank Statement Line and a Payment. Adding it to the dependencies of `_compute_from_payment_ids` will make reconciliations trigger the method. opw-4062387 Forward-Port-Of: odoo/enterprise#68547 Forward-Port-Of: odoo/enterprise#67519
Steps to reproduce: - Create a partner with a ref "PARTNER01" - Import a FEC with the same partner ref Issue: You will 2 same contacts Cause: During the refactor, the check existing partner has been taken out https://github.com/odoo/enterprise/commit/f60263a105717a7e00b1996b2b2e7b89e514ca54#diff-0c2b1931af025d6a908eea7d818a8858c6e9b03b436757b3c49ffa9857e55ae1L208-L227 Solution: The flow has slightly changed. To make sure the records already existing have an xml_id, we update them
Original PR description
Steps to reproduce: - Create a partner with a ref "PARTNER01" - Import a FEC with the same partner ref Issue: You will 2 same contacts Cause: During the refactor, the check existing partner has been taken out https://github.com/odoo/enterprise/commit/f60263a105717a7e00b1996b2b2e7b89e514ca54#diff-0c2b1931af025d6a908eea7d818a8858c6e9b03b436757b3c49ffa9857e55ae1L208-L227 Solution: The flow has slightly changed. To make sure the records already existing have an xml_id, we update them opw-3932234 Forward-Port-Of: odoo/enterprise#63895
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
**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/enterprise#66496## Issue: When validating a stock picking, in a Mondial relay delivery, if the partner created for it has no parent_id, the code will raise an error. ## Steps to reproduce: - Create a sendcloud delivery method (mondial relay) - go to website and order a product, go to checkout - pick sendcloud delivery method - select a relay location - go to odoo backend, go the sale order created by the website - click the SO deliveries smart button - change the quantity to the same as demand - cli
Original PR description
## Issue: When validating a stock picking, in a Mondial relay delivery, if the partner created for it has no parent_id, the code will raise an error. ## Steps to reproduce: - Create a sendcloud delivery method (mondial relay) - go to website and order a product, go to checkout - pick sendcloud delivery method - select a relay location - go to odoo backend, go the sale order created by the website - click the SO deliveries smart button - change the quantity to the same as demand - click on the delivery address - remove the partner's parent_id - add an email and phone number to the partner and save - go back to the picking page and click validate - a traceback will appear ## Solution: - in the `_prepare_parcel_common_data` method, raise a user error if the SO has `access_point_data` and the partner has no parent_id. OPW-4042529 Forward-Port-Of: odoo/enterprise#67074
When auofilling towards the right the last colmn of a pivot whose column are grouped by date, we got a traceback. This was due to the fact that we were trying to use the measure string as argument of `increment_date`. Task: [4045799](https://www.odoo.com/web#id=4045799&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form) Forward-Port-Of: odoo/enterprise#68358
Original PR description
When auofilling towards the right the last colmn of a pivot whose column are grouped by date, we got a traceback. This was due to the fact that we were trying to use the measure string as argument of `increment_date`. Task: [4045799](https://www.odoo.com/web#id=4045799&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form) Forward-Port-Of: odoo/enterprise#68358
This will add rules for the "Crédit d'impôt salarié" and for the "Crédit d'Impôt pour Compensation taxe Carbone" to the Luxembourg loca. Task: 3970107 Forward-Port-Of: odoo/enterprise#68439 Forward-Port-Of: odoo/enterprise#64260
Original PR description
This will add rules for the "Crédit d'impôt salarié" and for the "Crédit d'Impôt pour Compensation taxe Carbone" to the Luxembourg loca. Task: 3970107 Forward-Port-Of: odoo/enterprise#68439 Forward-Port-Of: odoo/enterprise#64260
Versions: ------------ 17.0 Steps to reproduce: ------------------------- 1. Send a sign request with 2 signers, setting a reminder to be sent every day. 2. Two emails will be sent to different signers. 3. Change the local date to 2 days ahead. 4. Run the "Send: Sign Reminder" cron. - Two more emails will be received, and one signer will complete their sign request. 5. Change the dates again and run the cron job. - One email will be sent to the remaining signer. 6. From the
Original PR description
Versions:
------------
17.0
Steps to reproduce:
-------------------------
1. Send a sign request with 2 signers, setting a reminder to be sent every day.
2. Two emails will be sent to different signers.
3. Change the local date to 2 days ahead.
4. Run the "Send: Sign Reminder" cron.
- Two more emails will be received, and one signer will complete their sign request.
5. Change the dates again and run the cron job.
- One email will be sent to the remaining signer.
6. From the old sign request email, copy the link and try to resend it.
- The user should not be able to resend the new link.
Issue:
-------
Resending the link does not check the state of the sign request and items, allowing multiple sends.
Solution:
-----------
Resending the link is only possible if the request and items are not already completed, canceled, or refused.
task: 4002440
Forward-Port-Of: odoo/enterprise#65853We 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