Tuesday, November 9, 2021
33 changes · master
New functionality added to Odoo
Odoo Mail now supports rich previews for shared links using oEmbed, making messages more visual and informative. It also improves link detection for URLs containing accented or international characters, so more shared content is recognized correctly.
Original PR description
oEmbed (https://oembed.com) is a format for allowing an embedded representation of a URL on third party sites like Odoo. task-2365881
A ready-to-use "Access Course" product is added when online course sales are enabled, helping businesses start selling paid courses faster. Course products now have a dedicated type and show customers which courses they will receive access to in the cart and sales orders.
Original PR description
Purpose ======= This commit adds a default product called "Access Course" to the database when you have the `website_sale_slides` installed. This commit also starts the transition for courses…
Purpose ======= This commit adds a default product called "Access Course" to the database when you have the `website_sale_slides` installed. This commit also starts the transition for courses products into `event ticket`-like products Specifications ============== This product is already created in order to help the users start to sell their courses. We also added a new type of product named `Courses`. This will be used to create courses and easily work with courses products. The commit adds the list of all the courses that the will gain access to when he will buy the product inside of the cart and in the right column whe it appears. It also adds the same list when the product is inserted into a sales order. The commit adds the choice of enroll policies in the front-end when `website_sales_slides` is installed and of the corresponding product if we are creating a paid course. task-2636092 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
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
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
Portal users now see fewer internal-only settings, reducing confusion when their profiles are managed. Non-internal users are also set to receive notifications by email, which ensures they still get updates even without access to Discuss.
Original PR description
Purpose ======= Hide non-relevant fields for a portal user. E.G. we want to hide the notification type, the menu customization... Because those fields make no sense for a portal user. In this PR we make onchange works on reified field to allow fields depending on groups to be modified as regular onchange in form view. Force the non-internal user to receive notifications by emails since they can not open Discuss. Task-2508521
The reception report no longer opens automatically based on a single inventory-wide setting. Businesses can now decide which operation types should show it, reducing unwanted interruptions during workflows like internal transfers or multi-step receipts.
Original PR description
Previously this setting was an application setting which meant the report could auto-open at undesired times (e.g. internal picking when multi-step). Instead we make it more flexible for the user's desires by moving it to the picking type setting. Task: 2632884 ~ENT PR: odoo/enterprise#20690~ Upgrade PR: odoo/upgrade#2815 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Helpdesk screens and related workflows were updated to be clearer and faster for everyday users. Changes improve ticket handling, SLA setup, coupon handling, field service task creation, and refund selection with better defaults, labels, warnings, and simplified forms.
Original PR description
The purpose of this commit is to make generic UX improvements in helpdesk. So in this commit following changes are made: Ticket: -'Helpdesk Team' renamed to 'Team' -Ticket Type hide the sequence…
The purpose of this commit is to make generic UX improvements in helpdesk. So in this commit following changes are made: Ticket: -'Helpdesk Team' renamed to 'Team' -Ticket Type hide the sequence field on creation -Tags creation: instead of numeric value color picker is added for the color field -'SLA Policies' is enbaled by default when a team is created -kanban view progressbar reprsents state of the tickets instead of activities -editing and creating on SOL's form view is prevented -'SLA Deadline' field moved to the right of SLA tags -'Priority' field moved above ticket type id -'Company' field moved to debug mode -values of priority field changed -modifying email and phone on ticket makes changes in partner phone and email as well. -warning displayed when email and phone of partner on ticket is changed -'Share on the forum' changed to 'Share on forum' -default stages of new team are set new-in progress-done-cancelled Coupons: -in coupon model the Coupon Program set with the lowest sequence value by default. -Send By Email> mail composer default template value set to sale coupon mail template. -when clicked on 'Coupon' from ticket the cancel button brings user back to coupon program selection. -icon of coupon stat button set to fa-dollar FSM Tasks: -rename 'Tasks' stat button to 'Field Service Task' -rename 'Plan Intervention' to 'Create Task' -when fsm task created, description and SOL of the ticket are copied -creation of fsm task form view disabled Refunds: -rename 'Invoice to Refund' to 'Invoices to Refund' -disable creation of invoices -set the posted invoices linked to SO by default Configuration: -types: sequence field moved out of debug mode -SLA form view: -enabled creation of Types -transformed ticket_type_id to many2many -display color of the tags -disable creation of Stages -Tags list view color field set optional and displayed by default **TaskID: 2578147**
Field Service users can now create, sign, and send basic intervention reports without buying Studio. Studio is only needed for custom worksheet templates, reducing costs for teams that only need simple time and materials reporting.
Original PR description
**PURPOSE:** Currently, Studio is required to use the 'worksheets' feature in Field Service. Some customers are only interested in communicating the time they spent and the products they used for the…
**PURPOSE:** Currently, Studio is required to use the 'worksheets' feature in Field Service. Some customers are only interested in communicating the time they spent and the products they used for the intervention. They don't need custom worksheet templates, but they still have to pay 48eur per user in order to use the feature ,which is quite expensive. The goal of this task is to allow using basic worksheets without needing Studio. The users who want to have custom worksheets can always add Studio. **SPECIFICATIONS:** For settings in Field Service, -rename 'worksheets' into 'custom worksheets' -change the description into 'customize worksheet templates' -rename 'time and material' into 'time and material invoicing' Project Form view: change the descripton of the 'worksheets' feature into: 'create reports to be signed off by your customers' The 'sign report', 'send report' buttons, 'worksheet' stat button and the 'worksheet' feature should be visible as soon as fsm is installed -without Studio, the worksheet stat button should open a simple HTML field The following elements should only be visible if the 'worksheets' feature is enabled in the settings of field service: -the 'worksheet template' field on project.task project.project,product.template -the planning > by worksheet menu -the configuration > worksheet templates menu Adapt industry_fsm_report tour into industry_fsm Replace the content of the 'default worksheet' template by an HTML field **LINKS** Task-2597340
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
HR teams can now update the closing date for multiple appraisals at the same time. This makes batch-created appraisals easier to manage and reduces repetitive manual work.
Original PR description
Purpose: Recent changes in Employee allow user to create a lot of appraisals at once. But you can't edit anything on them on the same time. It's not efficient if you can create them in a batch, but not edit some fields. Thus, after this commit it is possible to multi-edit date_close. task - 2669593
This change restores previous behavior so modules that only add data can install correctly when other apps are already present. It prevents installation failures caused by models not being prepared at the right time, reducing disruption for customers adding localization or configuration packages.
Original PR description
This reverts commit 9cc4d6956b71291958114196107b1889109e92a1. How to reproduce the issue: - Starts from a database with some modules installed (account). - Install a module with data only (l10n_generic_coa) The models are not setup and the data fails to install. A proper fix would be to mark the registry as dirty when new models are added and only setup models when needed. Since the faulty commit was part of a bunch of optimization and the impact of this particular one is quite small, reverting it is a quick and easy fix waiting for a better one (maybe, one day). 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
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