Monday, May 17, 2021
29 changes · master
Enhancements to existing features
Currency exchange rates shown in the kanban overview are now rounded to two significant digits. This makes the display easier to read at a glance while preserving the information needed for day-to-day currency management.
Original PR description
Task: 2519395
The stock return process now checks the type of record before applying limits meant only for stock transfers. This lets other workflows reuse the return model with multiple records without being blocked unnecessarily, while keeping the existing stock transfer behavior unchanged.
Original PR description
Before this commit, We were checking for multiple `active_ids` before checking for `active_model` in context, which was blocking point if user want to use this model with `active_ids` with different `active_model`. With this commit, we are checking condition of multiple `active_ids` if `active_model` is `stock.picking`. so other users can use this model with `active_ids` without changing any flow. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The meeting count button and visual meeting indicator are now available through Calendar instead of depending on CRM. This makes meeting information accessible for partners even when CRM is not installed, improving consistency for users who rely on calendar scheduling.
Original PR description
Move the meeting stat button and kanban pill from CRM to Calendar, purpose is to allow its usage even if CRM is not installed as this makes more sense since this field is usually related to Calendar. Increase query number limit in company leave test, in order to take into account the newly introduced query in Calendar. UPG-PR: odoo/upgrade#2423 Task-2514473 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Contact and course views now show a clearer attendee list with enrollment date, last activity date, progress, and related course details. This helps teams better understand student engagement and identify who may need follow-up across eLearning courses.
Original PR description
currently, when we click on the stat button "x Courses" on a contact we land on the dashboard of the courses that this user follows. but we would like to have more information about the progress of…
currently, when we click on the stat button "x Courses" on a contact we land on the dashboard of the courses that this user follows. but we would like to have more information about the progress of this student on each course. for instance, more than the progress, we may want to see when was the last time our student was active on a course. below listed are the major changes done for this improvement. in elearning view of contact form : 1. replaced the view from the stat button by a view list and added default search filter = contact in contact module. 2. added new column 'last action on' where it is the date from the last action. 3. changed the existing view to the following order of columns listed below 'course name', 'responsible', 'enrolled on', 'last action on' and 'progress' besides that, 'course type', 'visibility', 'enroll policy' and 'website' are changed into conditional columns. in e-learning module: 1. renamed 'created on' to 'enrolled on' as it will be more meaningfull to the context 2. in member view, 'last action on' field is added next to 'enrolled on '. 3. added a default search filter with the name of the course in member view, so that we can display all the attendees from all courses. 4. added a new menu "attendees" under the reporting menu which has the following columns : enrolled on, contact, email, course name, responsible, last action on and progress with a default group filter of 'channel_id' Task-Id : 2409447
Links created through user-generated content in the editor, forum, and profile areas are now marked with a standard attribute that identifies them as user-submitted. This helps search engines and other services better understand the origin of those links, reducing reputational risk from community content.
Original PR description
+ Odoo Editor Lib Build See odoo task : https://www.odoo.com/web#action=333&active_id=1695&cids=1&id=2319575&menu_id=4720&model=project.task&view_type=form -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Live previews in Mail-related fields now update only after the user pauses typing, rather than repeatedly during typing. This reduces unnecessary processing and helps avoid performance issues, especially with heavier content such as media previews.
Original PR description
…debounce The FieldChar and the "Emoji" fields support a "onchange_on_keydown" attribute that allow triggering the onchange event when the user types into the field. (Instead of having to wait for a…
…debounce The FieldChar and the "Emoji" fields support a "onchange_on_keydown" attribute that allow triggering the onchange event when the user types into the field. (Instead of having to wait for a blur event). This is especially useful, for example, in the social module to refresh the post preview when the user is typing his message. The current strategy to avoid spamming this onchange event was to throttle the method to trigger it at most once every second. However, triggering it every second could still be problematic in terms of performances and could cause loading issues (e.g: if you have a large GIF in your post preview) To try to mitigate this issue, we changed the strategy from throttle to debounce. Meaning the onchange will be triggered one second after the user is done typing, which still gives a nice "live update" effect without triggering the onchange too much. Task-2500821 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
The Documents spreadsheet feature has been updated with new usability enhancements, including hiding the grid, easier automatic sums, and better formula handling when inputs are missing. This should make spreadsheets more flexible and convenient for everyday business users while also including general reliability improvements and bug fixes.
Original PR description
Most notable improvements are: - allow to hide the grid - default value is used if a formula argument is missing - keyboard shortcut ALT+= to automatically sum data - various code improvements and refactorings - various bug fixes The complete changelog with all the new spreadsheet features and bug fixes can be found here: https://github.com/odoo/o-spreadsheet/releases/tag/3.0.0 (still unpublished at the time of writing this commit)
Managers can now see how each employee's recorded timesheet hours compare with their expected working hours directly in the timesheet grid. This makes it easier to spot overwork or under-allocation and rebalance people across projects.
Original PR description
Before this commit, when the grid view of timesheets is grouped by employee_id, we display the working schedule of each employee based of his resource calendar. However the manager should know the working schedule of his employees, but if he has a good indication of the workload of each employee, this can help the manager to find a better balance his resources accross projects. This commit changes the working schedules for each employee by the difference between the number of hours the employee is supposed to work on that period according to his resource calendar and the duration of his timesheets during that same period. task-2500800
Facebook posts can now include GIF files directly from the social posting flow. This makes campaign content more flexible by allowing animated media to be published correctly through Facebook.
Original PR description
This commit adds support for .gif upload when posting on Facebook. The Facebook API handles those GIFs by requiring to hit the '/videos' endpoint instead of the '/photos' endpoint. Indeed, for Facebook, a .gif file is fully considered as a video. Task-2500821
Resolved issues and error corrections
A missing supporting file was added to the live chat setup so PDF-related functionality can load correctly. This prevents potential errors caused by the live chat feature referencing a file that was not included in the expected bundle.
Original PR description
The module `@web/js/libs/pdfjs` was imported in the legacy file by PR #70375. So the file has to be added in external_lib bundle.
Features or functions removed from Odoo
This change removes an old comment from Odoo's configuration code that was added by mistake years ago. It has no effect on product behavior, but keeps the codebase cleaner and easier to maintain.
Original PR description
Apparently, it was added by mistake 7 years ago in https://github.com/odoo/odoo/commit/e9d047e6119d8065a8d31a7d3b374630ab90c40d 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
Before this commit, the wrong many2one value could have been selected in the tours, making it fail later on. 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#70749
Original PR description
Before this commit, the wrong many2one value could have been selected in the tours, making it fail later on. 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#70749
This fixes the website editor toolbar so list formatting controls appear together as a dropdown instead of stacking vertically. It restores the expected layout, making the editor cleaner and easier to use for content editing.
Original PR description
The list buttons in the toolbar were stacked, messing up the layout of the toolbar. This restores them as they were before https://github.com/odoo/odoo/commit/b2dd95937346561495ab86b90715210ffd9a474a somehow messed it up. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The email template screen now clarifies that the Reply-To setting applies to mass mailing only. This reduces confusion for users sending regular emails, who might otherwise expect that field to affect all outgoing messages.
Original PR description
Currently, the reply_to field is used only in the case of a mass mailing. Its label was misleading for users sending regular mail. We fix the label in order to avoid confusion. cc @Abridbus
The CRM Leads reporting list now uses the proper lead list view instead of an opportunity-focused view. Users can open lead records directly from the report list, making reporting navigation consistent with graph, pivot, and dashboard views.
Original PR description
PURPOSE When we go to CRM -> Reporting -> Leads, It shows the analysis of leads. We can open the form view of every leads from the different views wise Graph, 'Pivot', and 'Dashboard' except the 'List' view and it's a bit odd. We should be able to open the form view from corresponding leads in the list view. Currently, the view which is coming in the 'List' view is not correct and should be replaced by the same view which is rendered by action 'crm_lead_all_leads' SPECIFICATIONS - Initially, we have to fix the correct list view to be rendered and that is 'crm_case_tree_view_leads' instead of 'crm_case_tree_view_oppor'. - Next, we have added the form view in addition to the list view in view_ids of the corresponding action. This is the goal of this commit. LINKS PR #69575 Task 2497936
The CRM team reporting shortcut for Leads now opens the proper lead list instead of showing the opportunity list. This prevents confusion for sales teams and ensures lead reporting matches the selected menu option.
Original PR description
When clicking on "Teams -> Reporting (on a team vignette) -> Leads" list view used is the opportunity one. We fix it by correctly setting action views for ``action_report_crm_lead_salesteam`` reporting action. Task ID-2497936
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#70748 Forward-Port-Of: odoo/odoo#70457
Original PR description
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#70748 Forward-Port-Of: odoo/odoo#70457
Current behavior before PR: Traceback occurs when deleting company field task - 2475520 Forward-Port-Of: odoo/odoo#70467
Original PR description
Current behavior before PR: Traceback occurs when deleting company field task - 2475520 Forward-Port-Of: odoo/odoo#70467
When partner is not selected, Odoo sends name_search request `[..., ('partner_id', 'child_of', [False])]`. It's not obvious what does such domain mean ( see #70584 ). This commit clarifies what do we expect to get: we want all records without restrictions on `partner_id` value. This also fixes performance issue because domain leaf `('partner_id', 'child_of', [False])` is converted to where-clause `<table>.partner_id in <all or almost all ids>` --- opw-2524010 Description of the
Original PR description
When partner is not selected, Odoo sends name_search request
`[..., ('partner_id', 'child_of', [False])]`. It's not obvious what does such
domain mean ( see #70584 ). This commit clarifies what do we expect to get:
we want all records without restrictions on `partner_id` value.
This also fixes performance issue because domain leaf `('partner_id',
'child_of', [False])` is converted to where-clause `<table>.partner_id in <all
or almost all ids>`
---
opw-2524010
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#70638Issue - Install "Contacts" & 'base_address_extended' modules - Go to contacts and create a contact with value: - street name : Chaussee de Namur - House : 40 - Save and edit again - Set country to 'Netherlands' then save. Address not splited well (wrong values for street name and house). The issue is not present in UI but is in tests. (Issue in UI from odoo 14.0+) Cause There is 2 '_split_street_with_params' (inverse function that set street fields): - partne
Original PR description
Issue - Install "Contacts" & 'base_address_extended' modules - Go to contacts and create a contact with value: - street name : Chaussee de Namur - House : 40 - Save and edit again - Set country to…
Issue
- Install "Contacts" & 'base_address_extended' modules
- Go to contacts and create a contact with value:
- street name : Chaussee de Namur
- House : 40
- Save and edit again
- Set country to 'Netherlands' then save.
Address not splited well (wrong values for street name and house).
The issue is not present in UI but is in tests.
(Issue in UI from odoo 14.0+)
Cause
There is 2 '_split_street_with_params'
(inverse function that set street fields):
- partner_autocomplete_address_extended (removed in 14.0)
- base_address_extended
The 'spliting' logic is not the same in both function.
In UI, looks like it does not call '_split_street_with_params'
from 'base_address_extended' since no super(Partner, self)...
However in testing, it does call it from module
'base_address_extended' and therefore trigger the issue.
Solution
Adapt _split_street_with_params function
(in 'base_address_extended' module):
If previous field (from 'street_format') to parse
in 'street_raw' is 'street_name', then:
- set `tmp` to: splitted (max 1 split) street_raw
with current field seperator
- set `append_previous, sep, tmp[0]` to:
splitted tmp[0] (first part of splited street_raw) with `rpartition(' ')`
- add 'append_previous' to 'street_name' value
- join 'tmp' values and set it to street
(should equal to what left from `rpartition(' ')` split
+ second part of first normal split)
- continue normal parsing flow
opw-2476096
Forward-Port-Of: odoo/odoo#70783
Forward-Port-Of: odoo/odoo#70720In Ogone's backend, it is possible to remove `CARD.CARDNUMBER` from Flexcheckout's feedback data (Configuration -> Technical information -> Transaction feedback -> Alias gateway and Tokenization -> Dynamic parameters). Since this is the configuration that was suggested to Odoo customers migrating from a previous version, we must be able to process feedback data when the card number is missing. This commit creates an anonymous card number ('XXXX...') if one is not provided by Ogone. t
Original PR description
In Ogone's backend, it is possible to remove `CARD.CARDNUMBER` from
Flexcheckout's feedback data (Configuration -> Technical information ->
Transaction feedback -> Alias gateway and Tokenization -> Dynamic
parameters). Since this is the configuration that was suggested to Odoo
customers migrating from a previous version, we must be able to process
feedback data when the card number is missing.
This commit creates an anonymous card number ('XXXX...') if one is not
provided by Ogone.
task-2494916
Forward-Port-Of: odoo/odoo#70875- fix missing access rights when handling feedback data - redirect customers to the payment confirmation page when notification data are not acknowledged by PayPal, rather than displaying an internal server error task-2494916 Forward-Port-Of: odoo/odoo#70862
Original PR description
- fix missing access rights when handling feedback data - redirect customers to the payment confirmation page when notification data are not acknowledged by PayPal, rather than displaying an internal server error task-2494916 Forward-Port-Of: odoo/odoo#70862
Before this commit, in Project App, when the "Collaborative Pads" is enabled in the Settings of this app, if the user create a task without project or in a project that has not the pad enabled and he writes a description for his new task and select (another) project in which the pads is enabled then the description field in the form view changed to have the collaborative pad and the problem is the description is not copied in the pad and seems erase/delete for the user. This commit chec
Original PR description
Before this commit, in Project App, when the "Collaborative Pads" is enabled in the Settings of this app, if the user create a task without project or in a project that has not the pad enabled and he…
Before this commit, in Project App, when the "Collaborative Pads" is enabled in the Settings of this app, if the user create a task without project or in a project that has not the pad enabled and he writes a description for his new task and select (another) project in which the pads is enabled then the description field in the form view changed to have the collaborative pad and the problem is the description is not copied in the pad and seems erase/delete for the user. This commit checks if the pad_content_field is not empty after generating the pad url for the new task/record, if it is the case then we copy the content in the pad and the user can continue his edition before saving the task/record. Step to reproduce: ----------------- 1. Go to Settings of the Project App and enable the Collaborative Pads 2. Go to the Project App, in the Projects dashboard (kanban view of projects) 3. Create two Projects (one called "Project A" and the other called "Project B") 4. Edit the Project B to activate the pad, that is, check the Use collaborative pads checkbox. 5. Go to the view list of tasks in the "Project A" 6. Click on "Create" button to create a task in the task form view. 7. Write a description for this task. 8. Change the project of this task by the Project B. With this change, the collaborative pad is actived for this task since the Project B has the pad, and then the description in the pad is empty rather than have the content that we have just written. task-2515150 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#70401
If an error occurred when sending the verification SMS in SEPA's form, the error was shown both in the payment form and in a notification. This commit prevents the notification from being shown. task-2494916 Forward-Port-Of: odoo/enterprise#18340
Original PR description
If an error occurred when sending the verification SMS in SEPA's form, the error was shown both in the payment form and in a notification. This commit prevents the notification from being shown. task-2494916 Forward-Port-Of: odoo/enterprise#18340
As we were clearing the taxes on the invoice line after having set its description, it would remove any tax set by prediction, most notably, intracom taxes. This tax clear was done to prevent using the default tax from being. Now, this is done when the invoice line is created, so that it only removes this default tax. Forward-Port-Of: odoo/enterprise#17033
Original PR description
As we were clearing the taxes on the invoice line after having set its description, it would remove any tax set by prediction, most notably, intracom taxes. This tax clear was done to prevent using the default tax from being. Now, this is done when the invoice line is created, so that it only removes this default tax. Forward-Port-Of: odoo/enterprise#17033
Forward-Port-Of: odoo/enterprise#18291 Forward-Port-Of: odoo/enterprise#18075
Original PR description
Forward-Port-Of: odoo/enterprise#18291 Forward-Port-Of: odoo/enterprise#18075
…port TaskID: 2528726 Forward-Port-Of: odoo/enterprise#18293
Original PR description
…port TaskID: 2528726 Forward-Port-Of: odoo/enterprise#18293
- Updated the WSDL URLs for new customer Task: https://www.odoo.com/web#id=2508208&action=4043&model=project.task&view_type=form&cids=2&menu_id=4720 Forward-Port-Of: odoo/enterprise#17758
Original PR description
- Updated the WSDL URLs for new customer Task: https://www.odoo.com/web#id=2508208&action=4043&model=project.task&view_type=form&cids=2&menu_id=4720 Forward-Port-Of: odoo/enterprise#17758
- When paying a sales order to renew or upsell a subscription, the tokenization of the transaction was forced and only compatible acquirers were shown. This was not necessary as no payment token is ever assigned to the subscription afterward. This is only true when a subscription is created when confirming the sales order. - If the tokenization of the transaction was not required by Subscriptions, it prevented other modules to require it. task-2494916 Forward-Port-Of: odoo/en
Original PR description
- When paying a sales order to renew or upsell a subscription, the tokenization of the transaction was forced and only compatible acquirers were shown. This was not necessary as no payment token is ever assigned to the subscription afterward. This is only true when a subscription is created when confirming the sales order. - If the tokenization of the transaction was not required by Subscriptions, it prevented other modules to require it. task-2494916 Forward-Port-Of: odoo/enterprise#18284