Wednesday, August 21, 2024
29 changes · saas-17.4
Resolved issues and error corrections
Chat previews no longer show an unnecessary sender email/name prefix when the message is already from the chat correspondent. This keeps the messaging menu and chat bubble previews cleaner and avoids confusing duplicate sender information for users.
Original PR description
Follow-up of https://github.com/odoo/odoo/pull/176485 PR above fixes an issue where messages without any author were not working in both messaging menu and chat bubble preview. This commit made the unintentional change to display `email_from` of message preview in chat. This is because `email_from` is provided even though it could be unused. The `mail.message_preview_prefix` wanted to intentionally do nothing when message author is the correspondent (of chat). This commit fixes this issue.  
This fix prevents the top bar transition from replaying every time users switch views or embedded actions in the Project app. It makes navigation feel steadier and avoids distracting repeated animations during normal work.
Original PR description
Steps to reproduce: - Open project app and select a project - Click on top bar button - Now either change the view or embedded action. Issue: - The whole transition is reapplied every time we change view or embedded action Reason: - The whole ```ControlPanel``` component is destroyed and rendered when we either click on the embedded action or view. - Transition Component doesn't have any specification for skipping a transition. Fix: - Adding ```transitionWhenMounted``` option to Transition Component and Service as well. task-4035839
Public Discuss pages now update the browser page title to match the selected chat or channel. This makes it easier for users to identify the conversation they are viewing, especially when multiple tabs are open.
Original PR description
When Discuss is used and a channel has been selected, the page title becomes the thread name. This was not working for public pages. It is now done manually after rendering instead of relying on action service. Task-4100218
Miscellaneous changes
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.
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…
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)
Forward-Port-Of: odoo/odoo#177177Steps to reproduce: - Sale > Quotations > New - Set customer and product - POS > Quotation/Order > Apply down payment > Pay - Sale > Quotation > Create invoice > Create draft Error because the down payment line is missing an account_id, as a result of this commit 50ce3ce1d98958241667d1122273abccd59874b7 we would pass account_id = False in vals_list sometimes, causing the account_id not to be filled in or inferred later. opw-4064906 --- I confirm I have signed the CLA and read the P
Original PR description
Steps to reproduce: - Sale > Quotations > New - Set customer and product - POS > Quotation/Order > Apply down payment > Pay - Sale > Quotation > Create invoice > Create draft Error because the down payment line is missing an account_id, as a result of this commit 50ce3ce1d98958241667d1122273abccd59874b7 we would pass account_id = False in vals_list sometimes, causing the account_id not to be filled in or inferred later. opw-4064906 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#176553
[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#177123
Forward-Port-Of: odoo/odoo#176489Instead 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#177197 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#177197 Forward-Port-Of: odoo/odoo#177081
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#177286 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#177286 Forward-Port-Of: odoo/odoo#176636
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
Fix of the COA: There was a bad assignation in the account rate difference profit/loss. As these are minor changes, we make this together with changes in the F29 report VAT base https://github.com/odoo/enterprise/pull/55365 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#170301 Forward-Port-Of: odoo/odoo#151611
Original PR description
Fix of the COA: There was a bad assignation in the account rate difference profit/loss. As these are minor changes, we make this together with changes in the F29 report VAT base https://github.com/odoo/enterprise/pull/55365 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#170301 Forward-Port-Of: odoo/odoo#151611
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
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
Previously fiscal position was calculated based on shipping address of customer even if onsite picking was chosen as delivery method this was wrong in case the store was in a different location, with a different fiscal position. Now if onsite picking is selected, a recomputation of fiscal position is triggered opw-3849823 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#176420 Forward-Port-Of: odoo/odoo#171225
Original PR description
Previously fiscal position was calculated based on shipping address of customer even if onsite picking was chosen as delivery method this was wrong in case the store was in a different location, with a different fiscal position. Now if onsite picking is selected, a recomputation of fiscal position is triggered opw-3849823 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#176420 Forward-Port-Of: odoo/odoo#171225
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: 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
Customers redirected from email have the access_token of invoice while subscription is expecting order access_token so it can not be paid for, and redirection on json url causes infinite loading and frozen screen. Steps to reproduce the issue: 1. Create a new subscription and confirm it 2. Create the invoice and confirm it 3. Send the invoice by email so the customer pay it 4. Select the payment method CARD by Stripe. 5. Select the option "Automate payments for this subscription" (
Original PR description
Customers redirected from email have the access_token of invoice while subscription is expecting order access_token so it can not be paid for, and redirection on json url causes infinite loading and frozen screen. Steps to reproduce the issue: 1. Create a new subscription and confirm it 2. Create the invoice and confirm it 3. Send the invoice by email so the customer pay it 4. Select the payment method CARD by Stripe. 5. Select the option "Automate payments for this subscription" (Automatically the option save my payment details will be selected) How this commits fixes the issue: Replace invoice access_token by the subscription access_token. opw-4080536 Forward-Port-Of: odoo/enterprise#67777
"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
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
vat base and change exempt base to exports account. Forward-Port-Of: odoo/enterprise#66086
Original PR description
vat base and change exempt base to exports account. Forward-Port-Of: odoo/enterprise#66086
### 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
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
Steps to reproduce the bug: - Create a storable product “P1” with BoM: - Component: C1 - Create a quality point: - Product: P1 - Operation: Manufacturing - Control per: Quantity - Control Frequency: All - Create a manufacturing order: - Product: P1 - Quantity: 20 - Confirm the MO - Set the qty producing 12 - click on the quality check: - Button Fail - Quantity: 5 - Valide the Mo and create a backorder - click on the quality check:
Original PR description
Steps to reproduce the bug: - Create a storable product “P1” with BoM: - Component: C1 - Create a quality point: - Product: P1 - Operation: Manufacturing - Control per: Quantity - Control Frequency:…
Steps to reproduce the bug:
- Create a storable product “P1” with BoM:
- Component: C1
- Create a quality point:
- Product: P1
- Operation: Manufacturing
- Control per: Quantity
- Control Frequency: All
- Create a manufacturing order:
- Product: P1
- Quantity: 20
- Confirm the MO
- Set the qty producing 12
- click on the quality check:
- Button Fail
- Quantity: 5
- Valide the Mo and create a backorder
- click on the quality check:
- Button Fail
- Quantity: 1
Problem:
A traceback is triggered:
```
File "/home/odoo/odoo V16/enterprise/quality_control/models/quality.py", line 370, in _move_line_to_failure_location
if not check._can_move_line_to_failure_location():
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/odoo V16/enterprise/quality_mrp/models/quality.py", line 49, in _can_move_line_to_failure_location
self.move_line_id = self.production_id.finished_move_line_ids.filtered(
^^^^^^^^^^^^^^^^^
File "/home/odoo/odoo V16/odoo/odoo/fields.py", line 1321, in __set__
write_value = self.convert_to_write(value, records)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/odoo V16/odoo/odoo/fields.py", line 3118, in convert_to_write
return value.id
^^^^^^^^
File "/home/odoo/odoo V16/odoo/odoo/fields.py", line 5154, in __get__
raise ValueError("Expected singleton: %s" % record)
ValueError: Expected singleton: stock.move.line(96, 98)
```
When we validate the MO to create the backorder, the `_split_productions`
function is called. This results in two move lines:
https://github.com/odoo/odoo/blob/4be8cac644c9471f98bf16e82825af0e9439e697/addons/mrp/models/mrp_production.py#L1837
The first one has a quantity of 15, which is the remaining quantity
to be processed, and the second line has a quantity of 5, which is the
quantity that has definitely failed. However, these two move lines are
supposed to be ordered first by the failed ones and then by the others.
Because, in the current situation, we take the move line with the
quantity of 15, reduce it by the 12 units processed in this MO,
leaving 3. As a result, we will have two remaining move lines:
3 + 5 (already failed), and both will be used in the backorder.
But if they were ordered by the failed ones first, we would subtract
12 from 5, resulting in -7, and then reduce the line with 15 - 7 = 8
in the move line that will be used in the backorder."
https://github.com/odoo/odoo/blob/4be8cac644c9471f98bf16e82825af0e9439e697/addons/mrp/models/mrp_production.py#L1848-L1858
opw-4064656
Forward-Port-Of: odoo/enterprise#68544
Forward-Port-Of: odoo/enterprise#67474Versions: ------------ 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#65853__Current behavior before commit:__ When a mega menu has the class `o_mega_menu_container_size`, it is translated by 50% to the left because of this line [1]. However it shouldn't be if it is displayed inside a dropdown menu. __Description of the fix:__ Unset `transform` of `.o_mega_menu_container_size` when it is inside an `.o_extra_menu_items` element. __Steps to reproduce the issue on runbot:__ 1. Add a mega menu to the website 2. In the Editor, set Mega Menu > Size to `Narrow` a
Original PR description
__Current behavior before commit:__ When a mega menu has the class `o_mega_menu_container_size`, it is translated by 50% to the left because of this line [1]. However it shouldn't be if it is displayed inside a dropdown menu. __Description of the fix:__ Unset `transform` of `.o_mega_menu_container_size` when it is inside an `.o_extra_menu_items` element. __Steps to reproduce the issue on runbot:__ 1. Add a mega menu to the website 2. In the Editor, set Mega Menu > Size to `Narrow` and save 3. Resize the window just enough that a dropdown menu appear 4. Open the dropdown menu -> The mega menu is offset to the left opw-4021738 [1]: https://github.com/odoo/odoo/blob/9835632/addons/website/static/src/scss/website.scss#L1294 Forward-Port-Of: odoo/odoo#172438
Steps to reproduce the bug: - Create a storable product “P1” with BoM: - Component: C1 - Create a quality point: - Product: P1 - Operation: Manufacturing - Control per: Quantity - Control Frequency: All - Create a manufacturing order: - Product: P1 - Quantity: 20 - Confirm the MO - Set the qty producing 12 - click on the quality check: - Button Fail - Quantity: 5 - Valide the Mo and create a backorder - click on the quality check: - Button Fail - Quantity: 1 Problem: A traceb
Original PR description
Steps to reproduce the bug: - Create a storable product “P1” with BoM: - Component: C1 - Create a quality point: - Product: P1 - Operation: Manufacturing - Control per: Quantity - Control Frequency:…
Steps to reproduce the bug:
- Create a storable product “P1” with BoM: - Component: C1
- Create a quality point: - Product: P1 - Operation: Manufacturing - Control per: Quantity - Control Frequency: All
- Create a manufacturing order: - Product: P1 - Quantity: 20
- Confirm the MO
- Set the qty producing 12
- click on the quality check: - Button Fail - Quantity: 5
- Valide the Mo and create a backorder
- click on the quality check: - Button Fail - Quantity: 1
Problem:
A traceback is triggered:
```
File "/home/odoo/odoo V16/enterprise/quality_control/models/quality.py", line 370, in _move_line_to_failure_location
if not check._can_move_line_to_failure_location():
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/odoo V16/enterprise/quality_mrp/models/quality.py", line 49, in _can_move_line_to_failure_location
self.move_line_id = self.production_id.finished_move_line_ids.filtered(
^^^^^^^^^^^^^^^^^
File "/home/odoo/odoo V16/odoo/odoo/fields.py", line 1321, in __set__
write_value = self.convert_to_write(value, records)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/odoo V16/odoo/odoo/fields.py", line 3118, in convert_to_write
return value.id
^^^^^^^^
File "/home/odoo/odoo V16/odoo/odoo/fields.py", line 5154, in __get__
raise ValueError("Expected singleton: %s" % record)
ValueError: Expected singleton: stock.move.line(96, 98)
```
When we validate the MO to create the backorder, the `_split_productions`
function is called. This results in two move lines:
https://github.com/odoo/odoo/blob/4be8cac644c9471f98bf16e82825af0e9439e697/addons/mrp/models/mrp_production.py#L1837
The first one has a quantity of 15, which is the remaining quantity
to be processed, and the second line has a quantity of 5, which is the
quantity that has definitely failed. However, these two move lines are
supposed to be ordered first by the failed ones and then by the others.
Because, in the current situation, we take the move line with the
quantity of 15, reduce it by the 12 units processed in this MO,
leaving 3. As a result, we will have two remaining move lines:
3 + 5 (already failed), and both will be used in the backorder.
But if they were ordered by the failed ones first, we would subtract
12 from 5, resulting in -7, and then reduce the line with 15 - 7 = 8
in the move line that will be used in the backorder."
https://github.com/odoo/odoo/blob/4be8cac644c9471f98bf16e82825af0e9439e697/addons/mrp/models/mrp_production.py#L1848-L1858
opw-4064656
Forward-Port-Of: odoo/odoo#177041
Forward-Port-Of: odoo/odoo#175355**Version:** - 17.0 **Step to reproduce:** - open the Calendar and navigate to Configuration > Settings - add Google credentials and sync it - create an event and then pause the sync. - again create an event and unpause the sync with Google Calendar - event fails to update on Google Calendar **Issue:** Currently, when an event is created during the sync_pause period, the `_google_insert` function will not be called. After unpausing the sync, the event will return an empty Google
Original PR description
**Version:** - 17.0 **Step to reproduce:** - open the Calendar and navigate to Configuration > Settings - add Google credentials and sync it - create an event and then pause the sync. - again create an event and unpause the sync with Google Calendar - event fails to update on Google Calendar **Issue:** Currently, when an event is created during the sync_pause period, the `_google_insert` function will not be called. After unpausing the sync, the event will return an empty GoogleEvent ID. **Solution:** This PR enables the synchronization to restart automatically when unpausing the Google Calendar. task-3731607 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#156037
When a blog cover is edited, a tag option is displayed while there is no `tag_ids` inside the `blog.blog` model because the `o_wblog_post_page_cover` appears on both the `blog.blog` covers and on the `blog.post` covers. This commit hides the blog tags option if the model of the cover is `blog.blog`. Steps to reproduce: - Go to blogs. - Select the "Travel" blog. - Edit. - Select the blog's cover. => A tag option could be specified. opw-4107748 Forward-Port-Of: odoo/odoo#177077 Fo
Original PR description
When a blog cover is edited, a tag option is displayed while there is no `tag_ids` inside the `blog.blog` model because the `o_wblog_post_page_cover` appears on both the `blog.blog` covers and on the `blog.post` covers. This commit hides the blog tags option if the model of the cover is `blog.blog`. Steps to reproduce: - Go to blogs. - Select the "Travel" blog. - Edit. - Select the blog's cover. => A tag option could be specified. opw-4107748 Forward-Port-Of: odoo/odoo#177077 Forward-Port-Of: odoo/odoo#176510
At the moment, JP is added at the start of the tax scheme vals. In Japan and after 2023-10-01, the expected value in the company_id is the "Registration Number for Qualified Invoice purpose in Japan" which starts with a T and does not want JP prepended to it. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#177144
Original PR description
At the moment, JP is added at the start of the tax scheme vals. In Japan and after 2023-10-01, the expected value in the company_id is the "Registration Number for Qualified Invoice purpose in Japan" which starts with a T and does not want JP prepended to it. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#177144