Thursday, May 20, 2021
30 changes · master
Enhancements to existing features
The web interface now loads key page templates at the same time as JavaScript assets instead of waiting for one step to finish before starting the next. This improves startup performance and can save around half a second during initial loading, making the system feel more responsive.
Original PR description
BEFORE: browser loads js assets first, then qweb, then makes other initialization. AFTER: load qweb in parallel with js assets. This saves ~500 ms in runbot 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
Sales and payment users can now specify which payment provider should be used when generating a payment link. This gives teams more control over the customer payment experience and helps route payments through the most appropriate provider.
Original PR description
Simplified version of #69334 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Lead mining requests now show clear warnings when no results are found or when credits are insufficient. This helps sales users quickly understand the problem and adjust their search or buy more credits without restarting the process.
Original PR description
This commit improves the crm.iap.lead.mining.request error handling by displaying the encountered error (currently one of "no results" or "insufficient credits") within a warning block on top of the form view. This allows the user to quickly understand what's going on and change his parameters to get results or buy additional credits if he's out. Furthermore, this commit simplifies the technical implementation by avoiding to re-create a separate crm.iap.lead.mining.request when we encounter an issue and instead allow the user to modify the current request with an error state. Task-2478427 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
Project tasks now keep their assigned customer when a project or parent task customer changes, avoiding unexpected bulk updates. New tasks still receive sensible default customers from their project or parent task, and project cards show the commercial customer consistently.
Original PR description
Purpose ====== During the development of the task #2169100, it appeared that the synchronisation of a task's partner_id according to its project's partner_id and its parent's partner_id was not very…
Purpose
======
During the development of the task #2169100, it appeared that the synchronisation
of a task's partner_id according to its project's partner_id and its parent's
partner_id was not very clear.
A first idea was to simplify the partner_id management: as it could be annoying
for the customer to see all the task's partner_id overriden after project's
partner_id modification, the idea was to just use the parent's parnter_id or the
project's partner_id as default value of the task's partner_id. Then, if the
partner_id of the project or of the parent is changed, there is no more impact
on the task partner_id itself.
The main problem of this solution is that the management of the task's partner_id
is also extended in several others modules like sale_project and sale_timesheet.
You can find below what seems to happen with all these task partners.
Start following rules according to which module is installed.
(for the record: sale_timesheet depends on sale_project which depends on project).
Rules are applied in the order they are written.
Rules labelled "O" only apply when changing the project through the task form view.
Rules labelled "C" apply everywhere.
technical: C=compute, O=onchange
project
C.1 If parent's partner changes and the partner is not set, then set the parent's
partner
C.2 Else if project's partner changes ant the partner is not set, then set the
project's partner
sale_project [+ project]
C.1 If the project's sale order line's partner changes and the partner is not set,
then set the project's sale order line's partner
C.2 Else apply (project.C) rules
sale_timesheet + [sale_project + project]
C.1 Apply (sale_project.C) rules
O.1 If the project is billed "At Project rate" or "At Employee Rate" and the
partner is not set, then set the project's sale order's partner
the sale order line's partner
Specification
===========
- If the partner changes, we ignore all current tasks and let them be. We set the
new partner as default value on all new tasks. In detail, we have done
this:
- When the user creates a task give the customer of the default project or the
task parent as default customer for the task.
- When the user changes the project and no partner in the task, we take the
partner of the new project (if this project has a customer).
- When the user changes the customer of the project, the linked tasks are not
impacted by this changes, even if some tasks have not a customer yet.
- When the user changes the customerf of the parent task, the child tasks are
not impacted by this changes, event if these tasks have not a customer yet.
- remove the onchange rule to remain consistent.
- get the display_project_id if parent is subtask.
## Miscellaneous
- display commercial_partner_id in project kanban view rather than the partner_id
in the kanban card of each project to be consist with task's kanban card.
TaskID: 2232042
closes #51471
Co-authored-by: Xavier BOL (xbo) <xbo@odoo.com>Users can now choose or unchoose several companies from the company switcher without the page reloading after every single click. The system waits briefly before applying the changes, making multi-company switching faster and less repetitive.
Original PR description
PURPOSE Allow users to (de)select multiple companies from the company switcher before the page reloads. SPECIFICATION Give the user some time to (de)select another company before reloading the page. After the user has clicked on a company checkbox, wait 500ms. If after 500ms, the user hasn't clicked another checkbox, submit the changes and reload the page. This means that, as long as the user checks the multiple boxes within less than 500ms each time, he'll be able to select all the desired companies at once before the page reloads. TASK 2467747 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Many dropdown-style links across Odoo now use the standard searchable field while still preventing users from creating or opening linked records from those spots. This makes choosing existing records easier and removes the previous 100-item limitation without changing the intended restrictions.
Original PR description
currently, Across Odoo, there are around 40+ many2one fields defined with a
'selection' widget. Since the many2one widget has options to limit record
creation and opening, there is no reason to define a many2one field with a
selection widget. The selection widget does not allow for searching, and is
limited to 100 records.
PURPOSE
to update the definition of any many2one on which we applied a 'selection'
widget, and instead use the standard many2one widget with disabled
opening/creation instead.
after this commit,
for each many2one field defined with widget="selection", widget="selection" is
replaced with options="{'no_open': True, 'no_create': True}"
Task : 2476488
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThe mass mailing form now gives more space and attention to the email body, making campaigns easier to design. Settings are better organized, scheduling is clearer through a dedicated wizard, and empty emails show helpful guidance instead of a blank area.
Original PR description
Make the email body take the entire space to avoid having some wasted space, this will also make the user have more focus when designing an email. Revamp the settings notebook page in order to give more clarity to the user, furthermore, some fields from the main form have been moved to this section to have more space in the bottom for the email body. Add a wizard that enables the user to schedule a mailing, the schedule field is still kept in the form for the user to be able to change the date when the mailing is in the queue (if they want to send it sooner). Display an action helper-style content when the email is empty, because, currently, the user is left with a big white screen when the email has no content which is not desirable. Task-2469409 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The expense app demo data now uses clearer, more realistic expense categories with updated sample expenses and reports. The cost field help text was also clarified so users can better understand fixed versus variable expense costs during demos or evaluation.
Original PR description
Currently, in the expense module, demo expense products are more specific to the expenses and label tooltip of the cost field doesn't convey proper difference between fixed and variable cost of expense products. So in this commit, replace old expense products with new expense products and recreate expenses and reports using these categories(products). it will provide better experience on demo. overwrite label tooltip of cost field in expense app to convey proper difference between fixed and variable cost of expense products. Task-id: 2491238 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
Users can now create custom filters for file or image fields to find records where those fields are set or not set. This makes it easier to manage products, contacts, and other records that need attachments or images reviewed.
Original PR description
PURPOSE Allow to check whether a binary field is set or not by adding a basic filtering on binary fields. The main use case is to give users a way to filter records (e.g. products, contacts) that (do not) have a image set. SPECIFICATION Add binary fields to the list of field types usable in custom filters. The only supported operators are 'set' and 'not set' (just like when filtering based on a boolean field). TASK 2512226 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Users can now select or deselect several companies from the company switcher without the page reloading after every click. The system briefly waits before applying changes, making multi-company switching faster and less repetitive.
Original PR description
PURPOSE Allow users to (de)select multiple companies from the company switcher before the page reloads. SPECIFICATION Give the user some time to (de)select another company before reloading the page. After the user has clicked on a company checkbox, wait 500ms. If after 500ms, the user hasn't clicked another checkbox, submit the changes and reload the page. This means that, as long as the user checks the multiple boxes within less than 500ms each time, he'll be able to select all the desired companies at once before the page reloads. TASK 2467747
The mailing form in Marketing Automation now places the activities field below the source field. This small layout adjustment makes the form easier for users to understand and follow when setting up mailings.
Original PR description
This commit puts the activities field below the source field following community changes which aim at making the mailing form easier to understand by the user. Task-2469409 COM-PR: https://github.com/odoo/odoo/pull/68882
Several dropdown-style relationship fields now use Odoo’s standard searchable selector while still preventing users from creating or opening related records where that was intended. This makes choices easier to find and avoids the previous 100-item limit without changing the underlying business process.
Original PR description
currently, Across Odoo, there are around 40+ many2one fields defined with a
'selection' widget. Since the many2one widget has options to limit record
creation and opening, there is no reason to define a many2one field with a
selection widget. The selection widget does not allow for searching, and is
limited to 100 records.
PURPOSE
to update the definition of any many2one on which we applied a 'selection'
widget, and instead use the standard many2one widget with disabled
opening/creation instead.
after this commit,
for each many2one field defined with widget="selection", widget="selection" is
replaced with options="{'no_open': True, 'no_create': True}"
Task : 2476488Referral users can now be granted permission to view referral rewards and plan follow-up activities on them. This makes it easier for teams responsible for referral gifts to manage rewards directly without broader system access.
Original PR description
Refferal: Gift responsible access right improvement and activity view on Refferal Rewards configuration Add technical right for referral users. The referral users with this right should be able to see rewards and schedule activities on them Task - 2391337
Resolved issues and error corrections
This change ensures tracked links cannot be duplicated when they use the same URL and campaign details. It also makes link creation behave more predictably, so users see a clear error instead of being redirected to an existing record unexpectedly.
Original PR description
Purpose ======= Add a unicity constraint (main fields must have a unique combination). As we must care about null values, we can not implement it in SQL (possible in pure SQL, but we will need to create an index on the columns, which is not possible in Odoo if we want to customize the error message). Clean the code, before the "search or create" behavior was implemented in the create, causing strange behavior (creating a link tracker with the same values as an existing one didn't raise an error, but open the form view of the existing link tracker).
Code cleanup and technical improvements
The Sales module's internal Python files were split and renamed to better match the business objects they manage, such as sales orders, payments, invoices, and campaigns. This does not introduce new user-facing features, but it makes the codebase clearer and easier to maintain for upcoming improvements.
Original PR description
The `sale` code is going to experience some refactorings/improvements soon, and in preparation of those tasks, we believed it was time to reorder the python files. Splitting files according to python classes, and using targeted names as file names will improve the clarity and maintainability of the module, easing the future work.
To conserve the blame history of the splitted files, the file split are done in 2+ commits.
* `account_move.py` & `account_invoice.py` -> `account.move{.line}.py`
* `payment.py` -> `payment_acquirer.py` & `payment_transaction.py`
* `sale.py` -> `sale.order{.line}.py`
* `utm.py` -> `utm_campaign.py`
Moved the `mail_compose_message.py` file to the `wizard` folder, since it targets a wizard.
--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prMiscellaneous changes
The requests_toolbelt package < 0.9 uses `from collections import ...` which is deprecated in python 3.8 [0]. The request_toolbelt package is not a dependency of Odoo but is needed by zeep [1]. Unfortunately, the Ubuntu python3-requests-toolbelt package is still 0.8 [2]. This commit filters out the warning. [0] https://github.com/requests/toolbelt/commit/979f95266c2044893b05cb2314e94c899915748c [1] https://packages.ubuntu.com/focal/python3-zeep [2] https://packages.ubuntu.com/focal
Original PR description
The requests_toolbelt package < 0.9 uses `from collections import ...` which is deprecated in python 3.8 [0]. The request_toolbelt package is not a dependency of Odoo but is needed by zeep [1]. Unfortunately, the Ubuntu python3-requests-toolbelt package is still 0.8 [2]. This commit filters out the warning. [0] https://github.com/requests/toolbelt/commit/979f95266c2044893b05cb2314e94c899915748c [1] https://packages.ubuntu.com/focal/python3-zeep [2] https://packages.ubuntu.com/focal/python3-requests-toolbelt 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#70137
Fixed an issue in Point of Sale where reprinting a receipt could randomly fail because the receipt content was prepared in a way that was not always available. This makes receipt reprints more dependable for cashiers and reduces disruptions at checkout.
Original PR description
Because the `receiptHtml` was taken from a component which was mounted outside of the DOM, it was hardly ever destroyed for some unknown reasons and the `el.outerHTML` could not be taken to create the receipt.
The update fixes how existing tracking links are reused when referral or social push notification links are created. This prevents confusing behavior where creating a duplicate link could unexpectedly open an existing record instead of following a clear reuse process.
Original PR description
Purpose ======= Clean the code, before the "search or create" behavior was implemented in the create, causing strange behavior (creating a link tracker with the same values as an existing one didn't raise an error, but open the form view of the existing link tracker). Task-2090344
If a MO is validated with all of its (component) move_raw_ids.quality_done = 0, then when trying to validate the nonsensical "The quantity to produce must be positive" validation error will occur. This is due to all move_raw_ids being marked as Cancelled, which auto-updates the MO state to cancelled, which prevents the validation from properly completing. To avoid this error, we prevent the user from having 0 consumption for all components. Task: 2422698 Related (v13 fix + bug descr
Original PR description
If a MO is validated with all of its (component) move_raw_ids.quality_done = 0, then when trying to validate the nonsensical "The quantity to produce must be positive" validation error will occur. This is due to all move_raw_ids being marked as Cancelled, which auto-updates the MO state to cancelled, which prevents the validation from properly completing. To avoid this error, we prevent the user from having 0 consumption for all components. Task: 2422698 Related (v13 fix + bug description) Task: 2463893 ENT PR (test fixes): odoo/enterprise#18355 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#70900
**Description of the issue/feature this PR addresses:** Fixes a recursion error and data inconsistency resulting from the update of quantities for the components of a kit product from a kit variant. **Steps to reproduce the error:** With stock locations activated: - Create and configure a storable product with two variants (kit). - Create a storable product (component). - Create the BoM for the kit and add the component in the BoM Lines. - From the kit template, navigate to one of the ki
Original PR description
**Description of the issue/feature this PR addresses:** Fixes a recursion error and data inconsistency resulting from the update of quantities for the components of a kit product from a kit variant.…
**Description of the issue/feature this PR addresses:** Fixes a recursion error and data inconsistency resulting from the update of quantities for the components of a kit product from a kit variant. **Steps to reproduce the error:** With stock locations activated: - Create and configure a storable product with two variants (kit). - Create a storable product (component). - Create the BoM for the kit and add the component in the BoM Lines. - From the kit template, navigate to one of the kit variants and click on Update Quantity. - Add new quantities for the component. - Try to go back to the product and you will get the error. **Current behavior before PR:** When updating the quantities available for a product, an inventory move is generated without setting the product_tmpl_id, as this field is related to the product_id of the move. However, when creating the move, Odoo will consider it a default missing value and will try to fill it in the method default_get. The problem when dealing with kits is that the products available to update their quantities are the components of the kit. When navigating to a variant and updating the quantities of a component of the kit variant, the default product template in the context will be the kit template. This is causing that, when generating the inventory move, the move is created with product_id of the component, and product_tmpl_id of the kit template. This issue creates a critical data inconsistency as the component's template is set to the kit's template, which apart from making no sense generates a recursion error. **Desired behavior after PR is merged:** By preventing setting a default product template when the action to create/update quants is triggered for kit products, we prevent writing a wrong template. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#71037
Before this commit, Share action was displayed on list view as well which doesn't makes sense as it will always use `active_id` only. With this commit, we are displaying `Share` action on form view only. OPW 2530652 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#70821
Original PR description
Before this commit, Share action was displayed on list view as well which doesn't makes sense as it will always use `active_id` only. With this commit, we are displaying `Share` action on form view only. OPW 2530652 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#70821
Before this commit, we use the 'product.product_category_3' external_xmlid to find the 'Services' category but this record is in fact a demo data. This commit removes this using to create a new category called 'Services' for the product created in this test. Related PR: #65146 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#70730
Original PR description
Before this commit, we use the 'product.product_category_3' external_xmlid to find the 'Services' category but this record is in fact a demo data. This commit removes this using to create a new category called 'Services' for the product created in this test. Related PR: #65146 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#70730
The web editor does not work well with the e-learning fullscreen view. It actually completely closes the fullscreen view and opens the edition on a blank page. To avoid this, we intercept the click on the 'edit' button and redirect to the non-fullscreen view of this slide with the editor enabled, whose layout is more suited to edit in-place anyway. A small testing tour was added to ensure this behavior is kept. Task-2507179 Description of the issue/feature this PR addresses: C
Original PR description
The web editor does not work well with the e-learning fullscreen view. It actually completely closes the fullscreen view and opens the edition on a blank page. To avoid this, we intercept the click on the 'edit' button and redirect to the non-fullscreen view of this slide with the editor enabled, whose layout is more suited to edit in-place anyway. A small testing tour was added to ensure this behavior is kept. Task-2507179 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#71025 Forward-Port-Of: odoo/odoo#69363
The value taken into account in the SQL for the calculation were wrong: - Not based on the state of the invoices (cancelled and draft were taken into account) - Had the tax included opw-2464004 feedback-2478356 Forward-Port-Of: odoo/odoo#70592 Forward-Port-Of: odoo/odoo#70536
Original PR description
The value taken into account in the SQL for the calculation were wrong: - Not based on the state of the invoices (cancelled and draft were taken into account) - Had the tax included opw-2464004 feedback-2478356 Forward-Port-Of: odoo/odoo#70592 Forward-Port-Of: odoo/odoo#70536
-If the Service Invoicing Policy of the product is Prepaid or Milestones then the project with Billable active will also appear and create a task by product. -If service_policy changes, the project field will be empty. TaskID-2522084 Forward-Port-Of: odoo/odoo#71083 Forward-Port-Of: odoo/odoo#70609
Original PR description
-If the Service Invoicing Policy of the product is Prepaid or Milestones then the project with Billable active will also appear and create a task by product. -If service_policy changes, the project field will be empty. TaskID-2522084 Forward-Port-Of: odoo/odoo#71083 Forward-Port-Of: odoo/odoo#70609
The "Accept Terms & Conditions" toggle had been mistakenly removed from the "Customize" tab by commit 573ed74. task-2494916 Forward-Port-Of: odoo/odoo#71045
Original PR description
The "Accept Terms & Conditions" toggle had been mistakenly removed from the "Customize" tab by commit 573ed74. task-2494916 Forward-Port-Of: odoo/odoo#71045
Currently, create a service product and select a project or a project template from the 'sales' tab, it is not possible to select projects with allow_timesheets = false So in this commit, the domain of the project_id and the project_template_id fields should include projects for which allow_timesheets is false except if the 'Timesheets on tasks' option is selected as a service_policy Related PR: odoo/odoo#70609 Task-ID: #2522084 Forward-Port-Of: odoo/enterprise#18415
Original PR description
Currently, create a service product and select a project or a project template from the 'sales' tab, it is not possible to select projects with allow_timesheets = false So in this commit, the domain of the project_id and the project_template_id fields should include projects for which allow_timesheets is false except if the 'Timesheets on tasks' option is selected as a service_policy Related PR: odoo/odoo#70609 Task-ID: #2522084 Forward-Port-Of: odoo/enterprise#18415
Add a missing `sudo()` in `retry_ocr`. Bug introduced in 75fab554980. Forward-Port-Of: odoo/enterprise#18405
Original PR description
Add a missing `sudo()` in `retry_ocr`. Bug introduced in 75fab554980. Forward-Port-Of: odoo/enterprise#18405
Some enterprise level tests were incorrectly not consuming any of their components. This leads to broken tests when adding in a community check that prevents 0 component consumption in MOs. COM PR: odoo/odoo#70900 Forward-Port-Of: odoo/enterprise#18355
Original PR description
Some enterprise level tests were incorrectly not consuming any of their components. This leads to broken tests when adding in a community check that prevents 0 component consumption in MOs. COM PR: odoo/odoo#70900 Forward-Port-Of: odoo/enterprise#18355
Forward-Port-Of: odoo/enterprise#18397
Original PR description
Forward-Port-Of: odoo/enterprise#18397