Tuesday, November 9, 2021
25 changes · master
Enhancements to existing features
This update reorganizes how mail activity actions are managed behind the scenes. It should make the activity feature easier to maintain and support future improvements without changing the user experience.
Original PR description
Part of task-2579306
Portal users will no longer see VOIP settings that are only relevant to internal employees. This reduces confusion by keeping user settings focused on features they can actually use.
Original PR description
Purpose ======= Hide the VOIP for a portal user because it makes no sense for him (it makes sense only for internal users). Task-2508521
Resolved issues and error corrections
This fixes a rounding issue in landed cost calculations by using the company currency's precision instead of a generic decimal precision. Businesses should see more consistent and accurate cost amounts when allocating landed costs.
Original PR description
…landed cost There is a rounding problem because of decimal precision so we are change it to currency precision. opw-2524218 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 obsolete transfer account setup code that is no longer used in accounting and several country-specific accounting modules. It has no expected impact on day-to-day users, but helps keep the system easier to maintain and reduces clutter for future updates.
Original PR description
`_prepare_transfer_account_for_direct_creation` is not used since https://github.com/odoo/odoo/commit/04522f01e6fdbf82a657b32b312449fd7d756f79 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
Miscellaneous changes
This PR fixes the date-pickers libraries and their customizations loading order. Also, it adapts the DateRangePicker's design to match the recent DateTimePicker's design revamp. Forward-Port-Of: odoo/odoo#76692
Original PR description
This PR fixes the date-pickers libraries and their customizations loading order. Also, it adapts the DateRangePicker's design to match the recent DateTimePicker's design revamp. Forward-Port-Of: odoo/odoo#76692
This commit normalizes the different feature/browser detection modules' implementations to avoid difference between "newer" implementation and legacy ones. Its main goal is to ease future maintainability by having only one single source of truth for feature detection and, also ensure fixes applied to one version are applied everywhere. Forward-Port-Of: odoo/odoo#78324
Original PR description
This commit normalizes the different feature/browser detection modules' implementations to avoid difference between "newer" implementation and legacy ones. Its main goal is to ease future maintainability by having only one single source of truth for feature detection and, also ensure fixes applied to one version are applied everywhere. Forward-Port-Of: odoo/odoo#78324
Steps to reproduce the bug: - install delivery and sale_management - Create a product with route "Buy + MTO" and a product with route "Buy" - Create a SO with both products - Confirm the SO Problem: A traceback is triggered, because in this case, we have two `stock.move`, so two` stock.rule` therefore, when accessing the `propagate_carrier` field an error will be thrown opw-2681427 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forw
Original PR description
Steps to reproduce the bug: - install delivery and sale_management - Create a product with route "Buy + MTO" and a product with route "Buy" - Create a SO with both products - Confirm the SO Problem: A traceback is triggered, because in this case, we have two `stock.move`, so two` stock.rule` therefore, when accessing the `propagate_carrier` field an error will be thrown opw-2681427 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#79509
Before this commit: Some navbar app sections items were not properly indented in dropdowns. After this commit: The indentation is restored, leading to a clearer usage of the navbar menus. 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#79540
Original PR description
Before this commit: Some navbar app sections items were not properly indented in dropdowns. After this commit: The indentation is restored, leading to a clearer usage of the navbar menus. 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#79540
Before this commit, the link popover was only available in the website builder. Now it is available anywhere the wysiwyg is used. Task-2678412 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#79289
Original PR description
Before this commit, the link popover was only available in the website builder. Now it is available anywhere the wysiwyg is used. Task-2678412 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#79289
In some flow like subscription, invoices are sent by mail automatically to the customer. Sometimes, the invoice must be approved by the government before sending the mail like the Mexican EDI. This commit aims to add a custom method to detect when an invoice is ready to be sent to the customer. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#79439 Forward-Port-Of: odoo/odoo#78714
Original PR description
In some flow like subscription, invoices are sent by mail automatically to the customer. Sometimes, the invoice must be approved by the government before sending the mail like the Mexican EDI. This commit aims to add a custom method to detect when an invoice is ready to be sent to the customer. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#79439 Forward-Port-Of: odoo/odoo#78714
Remove the Purchase Security Lead Time from the computing of the purchase order's picking deadline to better reflect that the shipment is actually meant to arrive earlier than date + security lead time. Meaning if we have a Purchase Security Lead Time of 30 days, when a reordering rule is triggered, the picking for the created purchase order won't be meant to come in 30+ days, but as soon as possible. Task-2656397 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.
Original PR description
Remove the Purchase Security Lead Time from the computing of the purchase order's picking deadline to better reflect that the shipment is actually meant to arrive earlier than date + security lead time. Meaning if we have a Purchase Security Lead Time of 30 days, when a reordering rule is triggered, the picking for the created purchase order won't be meant to come in 30+ days, but as soon as possible. Task-2656397 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#78199
**Description of the issue/feature this PR addresses:** Some fixes on the Austrian Localization Info: @wt-io-it -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#79419 Forward-Port-Of: odoo/odoo#79294
Original PR description
**Description of the issue/feature this PR addresses:** Some fixes on the Austrian Localization Info: @wt-io-it -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#79419 Forward-Port-Of: odoo/odoo#79294
Problem : Free Shipping is not translated in delivery New Behaviour : Free shipping will now be translated opw-2679727 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#79305
Original PR description
Problem : Free Shipping is not translated in delivery New Behaviour : Free shipping will now be translated opw-2679727 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#79305
Steps to reproduce the bug: - Install sale_management and sale_mrp - Create a product with BOM, which is a KIT and add any product in BOM line - Create a SO for the product > Confirm - Validate the delivery - Cancel the SO > Set to Quotation > Reconfirm Problem: A new delivery order is generated while the ordered quantity = delivered quantity This is because `_get_qty_procurement` wrongly computed the product quantity based on the moves quantities in the kit case. opw-2647856
Original PR description
Steps to reproduce the bug: - Install sale_management and sale_mrp - Create a product with BOM, which is a KIT and add any product in BOM line - Create a SO for the product > Confirm - Validate the delivery - Cancel the SO > Set to Quotation > Reconfirm Problem: A new delivery order is generated while the ordered quantity = delivered quantity This is because `_get_qty_procurement` wrongly computed the product quantity based on the moves quantities in the kit case. opw-2647856 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#79511 Forward-Port-Of: odoo/odoo#79387
Report client action can need context data to be properly be displayed. But because all the required data is not put in the url, reloading didn't work. However, there is the current action data kept in the session storage which is a solution to avoid the described problem. But it didn't work because of the implementation of the report client action execution. It was in reality executing two actions: one for the report, gathering the data and fallbacking to a client action. By doing this,
Original PR description
Report client action can need context data to be properly be displayed. But because all the required data is not put in the url, reloading didn't work. However, there is the current action data kept in the session storage which is a solution to avoid the described problem. But it didn't work because of the implementation of the report client action execution. It was in reality executing two actions: one for the report, gathering the data and fallbacking to a client action. By doing this, the session storage would not have the necessary data kept for reloading the page. The fix is simply to duplicate the code of the client action execution instead of calling doAction again. Forward-Port-Of: odoo/odoo#79517
How to reproduce the problem: - Install the Sales and Invoicing apps - Create a simple SO with a product - Create Invoice -> Down Payment (percentage) 30% -> confirm - On the SO -> Create Invoice -> with Deduct down Payment -> confirm - On that invoice -> Add Credit Note -> Reverse -> confirm On the SO, the Down payment is not counted as invoiced, even tough it was already paid and not refunded. If the user wants to create a new invoice, the system will create one with the full price (no
Original PR description
How to reproduce the problem: - Install the Sales and Invoicing apps - Create a simple SO with a product - Create Invoice -> Down Payment (percentage) 30% -> confirm - On the SO -> Create Invoice ->…
How to reproduce the problem: - Install the Sales and Invoicing apps - Create a simple SO with a product - Create Invoice -> Down Payment (percentage) 30% -> confirm - On the SO -> Create Invoice -> with Deduct down Payment -> confirm - On that invoice -> Add Credit Note -> Reverse -> confirm On the SO, the Down payment is not counted as invoiced, even tough it was already paid and not refunded. If the user wants to create a new invoice, the system will create one with the full price (not taking the already invoiced Down Payment into account). Cause of the problem : when computing the quantity to invoice for the SO, a condition was avoiding preventing the down payment invoice line to be taken into account in a way that it was just ignored. I don't really understand the reason for this condition, as it specifically ignores the down payments, while it should not be ignored. When creating the draft for the refund invoice, the down payment's SOL is correctly updated as `line.untaxed_amount_to_invoice == 0` is true. But when confirming the invoice, the values changed and the condition is thus not met anymore. opw-2491225 Forward-Port-Of: odoo/odoo#79443 Forward-Port-Of: odoo/odoo#78999
Commit d6abfbade9fb7f6dd6b3253551c559b1c7e6ece5 made it so we directly reference a move's source origin via _get_source_document(). Normally this is fine when the labels are created because labels would never be created for a move without a source document, but this isn't safe when the label is accessed via another way (e.g. test_reports). Therefore, let's add in a check to prevent a error from trying to access False.name. Description of the issue/feature this PR addresses: Current b
Original PR description
Commit d6abfbade9fb7f6dd6b3253551c559b1c7e6ece5 made it so we directly reference a move's source origin via _get_source_document(). Normally this is fine when the labels are created because labels would never be created for a move without a source document, but this isn't safe when the label is accessed via another way (e.g. test_reports). Therefore, let's add in a check to prevent a error from trying to access False.name. 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#79574
In some flow like subscription, invoices are sent by mail automatically to the customer. Sometimes, the invoice must be approved by the government before sending the mail to the customer like in the Mexican EDI. This commit aims to add a custom method to detect when an invoice is ready to be sent to the customer. Forward-Port-Of: odoo/enterprise#22140 Forward-Port-Of: odoo/enterprise#21809
Original PR description
In some flow like subscription, invoices are sent by mail automatically to the customer. Sometimes, the invoice must be approved by the government before sending the mail to the customer like in the Mexican EDI. This commit aims to add a custom method to detect when an invoice is ready to be sent to the customer. Forward-Port-Of: odoo/enterprise#22140 Forward-Port-Of: odoo/enterprise#21809
When helpdesk.team record is updated, _check_sla_group was triggered everytime, which caused to force enable/disable all SLAs. It is incorrect to trigger it every time on helpdesk team update, because there could be some archived SLAs that are not intended to be used, yet it would be unarchived and would mess up new tickets, where old SLA could take priority. It should be only triggered if we know what change was related with enabling/disabling SLA feature. opw:2658436 Co-author
Original PR description
When helpdesk.team record is updated, _check_sla_group was triggered everytime, which caused to force enable/disable all SLAs. It is incorrect to trigger it every time on helpdesk team update, because there could be some archived SLAs that are not intended to be used, yet it would be unarchived and would mess up new tickets, where old SLA could take priority. It should be only triggered if we know what change was related with enabling/disabling SLA feature. opw:2658436 Co-authored-by: oerp-odoo <andrius@focusate.eu> Forward-Port-Of: odoo/enterprise#22036
The literal_eval is supposed to transform a hypothetical stringified context into a dictionnary except that the context is a dictionnary, so this is useless. Fix for https://github.com/odoo/odoo/pull/78262#issuecomment-952109557 Forward-Port-Of: odoo/enterprise#22177
Original PR description
The literal_eval is supposed to transform a hypothetical stringified context into a dictionnary except that the context is a dictionnary, so this is useless. Fix for https://github.com/odoo/odoo/pull/78262#issuecomment-952109557 Forward-Port-Of: odoo/enterprise#22177
Mass mailing themes had a number of superfluous and wrong xml attributes typically copied from the DOM but not supposed to be found in templates. It was generally without consequence except in the case of the VIP theme where two images had the "o_modified_image_to_save" class, eventually causing a traceback on save. task-2680428 Forward-Port-Of: odoo/enterprise#22161
Original PR description
Mass mailing themes had a number of superfluous and wrong xml attributes typically copied from the DOM but not supposed to be found in templates. It was generally without consequence except in the case of the VIP theme where two images had the "o_modified_image_to_save" class, eventually causing a traceback on save. task-2680428 Forward-Port-Of: odoo/enterprise#22161
…balance - Create a company for mexico and install l10n_mx_reports_closing module - Create an invoice in the last fiscal year - Check the trial balance Only the receivable account is shown opw-2495326 Forward-Port-Of: odoo/enterprise#21991
Original PR description
…balance - Create a company for mexico and install l10n_mx_reports_closing module - Create an invoice in the last fiscal year - Check the trial balance Only the receivable account is shown opw-2495326 Forward-Port-Of: odoo/enterprise#21991
SwitchCompanyMenu is unvoluntarily onelined on mobile which introduce a horizontal scroll and is actually not very usable... The issue was probably introduced during the refactoring of the dropdown styling which applies unexpected styles on the company menu for mobile... which, in turn, isn't an actual dropdown. task-2666215 Forward-Port-Of: odoo/enterprise#21609
Original PR description
SwitchCompanyMenu is unvoluntarily onelined on mobile which introduce a horizontal scroll and is actually not very usable... The issue was probably introduced during the refactoring of the dropdown styling which applies unexpected styles on the company menu for mobile... which, in turn, isn't an actual dropdown. task-2666215 Forward-Port-Of: odoo/enterprise#21609
This commit restores the right alignement of the action menu (i.e. in list or form view) on smaller screens by... fixing a typo in the CSS class name. Forward-Port-Of: odoo/enterprise#21581
Original PR description
This commit restores the right alignement of the action menu (i.e. in list or form view) on smaller screens by... fixing a typo in the CSS class name. Forward-Port-Of: odoo/enterprise#21581
Steps to reproduce the bug: Create a tax included in price T1 Create a customer with a fiscal position that should replace the current tax T1 by a 0% tax T2 Create a subscription product with this tax and a unit price UP Create a subscription and invoice it Bug: UP was updated on the subscription line (it removed T1 from UP) So when generating several times a recurring invoice, UP was equal to 0 at the end. Fine tuning of https://github.com/odoo/enterprise/commit/163f9009d2eacfd896
Original PR description
Steps to reproduce the bug: Create a tax included in price T1 Create a customer with a fiscal position that should replace the current tax T1 by a 0% tax T2 Create a subscription product with this tax and a unit price UP Create a subscription and invoice it Bug: UP was updated on the subscription line (it removed T1 from UP) So when generating several times a recurring invoice, UP was equal to 0 at the end. Fine tuning of https://github.com/odoo/enterprise/commit/163f9009d2eacfd8968d4565c2f026f3ff813ae6 opw:2637567 Forward-Port-Of: odoo/enterprise#22152