Monday, March 20, 2023
71 changes · master
New functionality added to Odoo
Website editors can now add a ready-made cover section that combines an image with text on the side. This gives teams another flexible layout option for building more engaging pages without custom design work.
Original PR description
New text_cover snippet added for the editor. Editors are now able to use a cover composed of an image and some text on the side. task-2691555 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Enhancements to existing features
Employee forms now only show related shortcut buttons when there are records to open. This reduces confusion and helps users focus on relevant attendance, timesheet, training, and work entry information.
Original PR description
Don't show smartbuttons that lead to a view without records task - 3134772
Resolved issues and error corrections
The messaging menu and Discuss sidebar now show status icons with a background that matches the item behind them, including when users hover over entries. This fixes a visual inconsistency and makes the messaging interface look cleaner and more polished.
Original PR description
Fix im status icon background to match item background in messaging menu on hover Task-3050023 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Code cleanup and technical improvements
This update reorganizes and cleans up delivery-related configuration and view files without changing business workflows. It also fixes a translated warning title, making the delivery app slightly more polished for multilingual users.
Original PR description
--- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Miscellaneous changes
This commit fixes a regression introduced in https://github.com/odoo/odoo/pull/104323. That fix was preventing the default behavior of the 1st `.oe_login_form button[type=submit]` found. It turns out that, for allowing the mail plugin to work, you actually need to have the default behavior of that element working normally. Without this patch, the `&do=1` query is never added to the POST parameters. Thus, the user is unable to authorize their mail plugin. @moduon MT-2552 MT-2553 OPW-3230686
Original PR description
This commit fixes a regression introduced in https://github.com/odoo/odoo/pull/104323. That fix was preventing the default behavior of the 1st `.oe_login_form button[type=submit]` found. It turns out that, for allowing the mail plugin to work, you actually need to have the default behavior of that element working normally. Without this patch, the `&do=1` query is never added to the POST parameters. Thus, the user is unable to authorize their mail plugin. @moduon MT-2552 MT-2553 OPW-3230686 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#115630 Forward-Port-Of: odoo/odoo#115198
The point of sale reward selection popup now shows which loyalty program each reward belongs to. This helps cashiers choose the right reward more confidently when multiple programs are available.
Original PR description
Before this PR, the name of the program from which an award comes was not displayed in the selection popup. TaskId: 3069449 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Notification emails now translate buttons, access links, and signatures using each recipient's preferred language instead of the sender's language. This improves clarity for multilingual recipients and makes automated email communication feel more localized and professional.
Original PR description
Description of the issue/feature this PR addresses: The buttons, the access links and the signature of the email are not properly translated in the language of the recipients. Current behavior before PR: These components are translated in the language of the user who wrote the email (i.e: in the language of the context). Desired behavior after PR is merged: These components will be translated in the language of each recipient. Task id: 2555155
Employee badge PDF downloads now use a shorter, clearer file name: "badge - employee name" instead of "print badge - employee name". This makes downloaded badge files easier to identify and organize for HR users.
Original PR description
before this commit, on printing employee badge the download pdf file is named print badge - employee name after this commit, the downloaded file name will be changed to badge - employee name --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The mail app now calculates recent conversation activity when needed instead of storing it separately. This keeps the underlying data simpler and helps reduce the chance of outdated activity information being used.
Users can now mark mail and Discuss messages as unread, making it easier to return to important conversations later. This improves day-to-day message management and helps users keep track of items that still need attention.
Original PR description
task-3232911
This update simplifies how mail conversation display preferences are handled internally. It helps make the mail experience easier to maintain and less prone to inconsistent behavior, with minimal direct impact for users.
Time-off accruals now ignore future planned leave when calculating how many days an employee should earn. This prevents employees from temporarily scheduling future leave to inflate their accrual balance, while still allowing dashboards to show future leave where appropriate.
Original PR description
As it is now, an accrual gives days up until the limit of the current accrual plan. The computation decides how many days to add based on that limit and current allocated days - leaves_taken. Leaves_taken is all leaves taken in the past or in the future, that could be linked to the accrual. This means an employee can plan a leave in the future, which he does not intend to take, just to get more days from the accrual system. This commit introduces a boolean to pass to the main calculation function, to tell it to take into account or not the leaves in the future, because other parts of the system ( like the available time-off you can see in your dashboard ) do need to take into account future leaves. this closes task 3207843
Message actions in Mail now appear in a compact layout by default, showing key options like reactions, reply, and more actions. This makes conversations easier to scan and keeps common controls accessible without cluttering the interface.
Original PR description
- Message options always compact by default - when compact: reaction, reply, more Task-2362261
The mail emoji picker now shows recently used emojis, making it quicker for users to reuse their preferred reactions and symbols. This improves day-to-day messaging convenience by reducing the time spent searching for common emojis.
Original PR description
Task-2982627 
Product quantities on the e-commerce checkout page now appear without unnecessary decimal places. This makes the order review clearer for shoppers and reduces visual clutter during checkout.
Original PR description
Decimals were displayed in the quantity of products bought in the checkout page, which is not necessary. task-3135936
Customer records now include a shortcut showing the active loyalty cards linked to that customer. This helps sales and point-of-sale teams quickly review customer rewards without searching through loyalty records manually.
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
When multiple bank statements are imported together, valid statements are now processed even if another file has an error. Users receive either a success redirect, an error if all imports fail, or a warning listing failed files with access to the successfully imported statements.
Original PR description
Currently, when importing multiple bank statements, if one of them has an error, we block the others. With this commit, we will process all the statements and, if applicable, show an error message at the end. This allows correct statements to be imported even if one in the batch is failing. Therefore, we now have three flows: - Everything went smoothly, we can redirect the user to correct view - All the imports failed, we show an error - At least one import succeeded and at least one failed, we display a warning message containing the names of the attachments that were not imported and show an option to view the ones that were correctly imported task id 2747359
Employee screens now hide payroll and planning shortcut buttons when there are no related records to show. This reduces confusion by preventing users from opening empty views and keeps the interface focused on relevant actions.
Original PR description
Don't show smartbuttons that lead to the view without records task - 3134772
Australian KeyPay payroll tax lines can now be linked to the correct invoice taxes, making payroll-related invoicing more accurate and easier to reconcile. The update also improves date handling for KeyPay lock dates so records align better with KeyPay’s timezone behavior.
Original PR description
- Map KeyPay payroll tax lines to invoice taxes. - The taxes will map l10n_au_kp_tax_identifier to KeyPay tax code.
The chatter area has been adjusted to better match the expected visual design. Spacing, text styling, and separator borders were refined so users see a cleaner and more consistent communication panel.
Original PR description
This commits makes some improvement on the chatter visuals -Spacing/styling of the text over the chatter's composer -Extending the grey border separating composer from buttons   This PR is meant to adapt the refactoring's visuals closer to the master's visuals
This fixes an internal testing issue where some web tests could stop too early after a tour test reported success. The full web test suite now runs as intended, helping catch problems before they reach users.
Original PR description
Python tests that run chrome headless wait for "test successful" to be printed in the console to end the test with green status. Tours and qunit suites logs that message when their work is done. Commit [1] reworked the tour system and introduced some qunit tests of the tour engine. However, running fake tours in qunit tests produced the "test successful" message, which caused the end of the suite. As a consequence, only a small part of the WebSuite test suite was really executed. This PR makes the test suite executed integrally again, and fixes an issue in tests introduced by [1] which was hidden due to the above described problem. [1] odoo/odoo@3a798039d6f200f8e28448ddb6a2d3c46654a203
This fix separates contact phone validation logic from SMS-specific behavior, reducing unintended dependencies between the two areas. Businesses benefit from more reliable contact data handling even when SMS features are not involved or installed.
Original PR description
Fixes #79460. Related to #85254. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update cleans up parts of the Discuss chat logic and fixes a crash that could happen when opening a chat from the welcome bot. Users should see a more reliable live chat experience with no change to their usual workflow.
The VoIP service now stops safely if the phone connection component cannot start. This helps avoid broader errors in the app and gives users a more stable experience when call setup fails.
I confirm I am signing the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#115296
Original PR description
I confirm I am signing the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#115296
This commit avoids to update the related daterange field (aka. end date when changing start date, and vice-versa) when this field is not present in the DOM (could be 'invisible' field or hidden column in list). Steps to reproduce: - Open Field Service - Switch to list view - hide the End date column - select record(s) to enter multi edit mode - click on the Start date of the selected record to open the date range picker - select a new range - click Apply ==> Error saying that cannot re
Original PR description
This commit avoids to update the related daterange field (aka. end date when changing start date, and vice-versa) when this field is not present in the DOM (could be 'invisible' field or hidden column in list). Steps to reproduce: - Open Field Service - Switch to list view - hide the End date column - select record(s) to enter multi edit mode - click on the Start date of the selected record to open the date range picker - select a new range - click Apply ==> Error saying that cannot read setStartDate from undefined task-3200845 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#115658
Before this commit, deleting a record containing changes (dirty) recreated the record when leaving the view. Now, the changes are discarded when deleting the record so it is not marked as dirty and not recreated. task id: 3063834 Forward-Port-Of: odoo/odoo#115685
Original PR description
Before this commit, deleting a record containing changes (dirty) recreated the record when leaving the view. Now, the changes are discarded when deleting the record so it is not marked as dirty and not recreated. task id: 3063834 Forward-Port-Of: odoo/odoo#115685
Task: 947 **Description of the issue/feature this PR addresses**: VAT missing when printing Foregin Invoices **Current behavior before PR**: VAT missing when printing Foregin Invoices **Video Replicating the Issue**: https://drive.google.com/file/d/1sD3B3Hat8t61bCXZI8qnqdP4XKiiqFfM/view Partner information:  Invoice information:  Invoice information:  Printed invoice:  **Desired behavior after PR is merged**: VAT not missing when printing Foregin Invoices --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#112356 Forward-Port-Of: odoo/odoo#110483
Before this commit when in a multi-company environment an user could assign a company to the sale order and use taxes related to a different company for the sale order lines. This is a functional error and also provoques that taxes are not shown for some users when in a multi-company environment. After this commit a ValidationError will be raised whenever the company of the taxes in the sol and the so do not match. opw - 3117352 --- I confirm I have signed the CLA and read the PR gui
Original PR description
Before this commit when in a multi-company environment an user could assign a company to the sale order and use taxes related to a different company for the sale order lines. This is a functional error and also provoques that taxes are not shown for some users when in a multi-company environment. After this commit a ValidationError will be raised whenever the company of the taxes in the sol and the so do not match. opw - 3117352 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#115065 Forward-Port-Of: odoo/odoo#114836
Problem: When point_of_sale and pos_mercury are both installed, _gc_old_tokens will get called by the scheduled action "Base: Auto vacuum internal data" and it will try to remove the Vantiv tokens from POS orders that are 6+ months old. However, there are fields named ref_no and record_no that exists for pos.order; so the AttributeError will get thrown. Solution: It is safe to remove the entire method since the Mercury API documentation does not explicitly mandate the
Original PR description
Problem:
When point_of_sale and pos_mercury are both installed,
_gc_old_tokens will get called by the scheduled action "Base: Auto vacuum internal data"
and it will try to remove the Vantiv tokens from POS orders that are 6+ months old.
However, there are fields named ref_no and record_no that exists for pos.order;
so the AttributeError will get thrown.
Solution:
It is safe to remove the entire method since the Mercury API documentation
does not explicitly mandate the tokens be removed from old POS orders.
It was recommended by JOV to not modify the method to prevent the modification of
potentially 8 years old POS orders from client's databases.
Since the method is removed, the error will not be thrown when auto vacuum is called,
pos_mercury is installed, and POS orders are 6+ months older.
opw-3082616
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#114620Fixes a couple small issues: - ~~error when editing uom in scrap list view (**already fixed in v16 onwards**)~~ - incorrect error for product_qty constraints in unbuild (**~~should be~~ changed to SQL constraints in master**) - enforces cleaner manual user deletion of quants since some users were changing the standard access rights to be able to do this and causing reservation issues. We do this by ensuring the quant's `inventory_quantity` is set to 0 before unlinking it to unreserve the qt
Original PR description
Fixes a couple small issues: - ~~error when editing uom in scrap list view (**already fixed in v16 onwards**)~~ - incorrect error for product_qty constraints in unbuild (**~~should be~~ changed to SQL constraints in master**) - enforces cleaner manual user deletion of quants since some users were changing the standard access rights to be able to do this and causing reservation issues. We do this by ensuring the quant's `inventory_quantity` is set to 0 before unlinking it to unreserve the qty from any moves using that quant. Unfortunately we can only allow it for stock_managers without significant code change since `inventory_quantity` can only be changed by stock_managers. If users do the unlink while in superuser mode, then there's nothing we can do :shrug: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#114991 Forward-Port-Of: odoo/odoo#113349
after odoo #113888 when copy translations from one record to another, translations for non-installed languages may raise error these translations may be 1. created before the langauge is deactivated 2. en_US which is always available for non falsy translated field value this commit drops translations for uninstalled languages except 'en_US' when copy and prevent raising error when users want to translate en_US when en_US is not activated Description of the issue/feature this PR addres
Original PR description
after odoo #113888 when copy translations from one record to another, translations for non-installed languages may raise error these translations may be 1. created before the langauge is deactivated 2. en_US which is always available for non falsy translated field value this commit drops translations for uninstalled languages except 'en_US' when copy and prevent raising error when users want to translate en_US when en_US is not activated 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#115239
Following 873d6d9, the forecast would now redirect correctly to the corresponding bom when a `product.product` was used. The issue is that `bom_variant_ids` doesn't exist on `product.template`, raising a traceback when the forecast was accessed through the product themselves instead of their variants --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#115716
Original PR description
Following 873d6d9, the forecast would now redirect correctly to the corresponding bom when a `product.product` was used. The issue is that `bom_variant_ids` doesn't exist on `product.template`, raising a traceback when the forecast was accessed through the product themselves instead of their variants --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#115716
before this commit, on contact us form, except question input all the other required input field has * (asterisk) after the field label. after this commit, * will be added for the question input label in the contact us form --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#115683 Forward-Port-Of: odoo/odoo#115610
Original PR description
before this commit, on contact us form, except question input all the other required input field has * (asterisk) after the field label. after this commit, * will be added for the question input label in the contact us form --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#115683 Forward-Port-Of: odoo/odoo#115610
Steps to reproduce: - install hr_referral to have the group "group_hr_recruitment_referral_user"; - with a user, check "Recruitment Interviewer" (to access the Recruitment application); - with the same user, put the person as interviewer; - checked/uncheck the "Display CV on application form" parameter on the user; Issue: Depending on whether the CV is displayed or not, the display of the buttons differs in the chatter on the form view of a job application. Cause: The "hr_applicant_v
Original PR description
Steps to reproduce: - install hr_referral to have the group "group_hr_recruitment_referral_user"; - with a user, check "Recruitment Interviewer" (to access the Recruitment application); - with the same user, put the person as interviewer; - checked/uncheck the "Display CV on application form" parameter on the user; Issue: Depending on whether the CV is displayed or not, the display of the buttons differs in the chatter on the form view of a job application. Cause: The "hr_applicant_view_form_interviewer" view allows to hide the buttons only when the chatter is contained in the form container. Solution: Add the class that allows to hide the information with an override of the FormController component. opw-3202343 Forward-Port-Of: odoo/odoo#114548
task - 3203838 Forward-Port-Of: odoo/odoo#114280
Original PR description
task - 3203838 Forward-Port-Of: odoo/odoo#114280
Description of the issue/feature this PR addresses: In large database, to compute picking_count on orders and sessions, can take lot of time. @pimodoo @Whenrow --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#114553
Original PR description
Description of the issue/feature this PR addresses: In large database, to compute picking_count on orders and sessions, can take lot of time. @pimodoo @Whenrow --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#114553
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#115793
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#115793
**To reproduce:** - go in any view with a search bar and favorites - click on favorites and save current search or add to dashboard - click with the mouse anywhere inside the default text and begin typing (e.g. in between existing character of the default filter name) - the first letter will be at the spot you placed the mouse - the second letter will be at the end **Solution:** Remove the autofocus. Since the autofocus doesn't work and making it work might result to significant
Original PR description
**To reproduce:** - go in any view with a search bar and favorites - click on favorites and save current search or add to dashboard - click with the mouse anywhere inside the default text and begin typing (e.g. in between existing character of the default filter name) - the first letter will be at the spot you placed the mouse - the second letter will be at the end **Solution:** Remove the autofocus. Since the autofocus doesn't work and making it work might result to significant change in the code, then it's better to just remove the attempt to autofocus. An issue is posted in the owl repo to potentially provide better api for this kind of situation: https://github.com/odoo/owl/issues/1381 TASK-ID: 3221734 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#115484
This commit deactivates the daterangepicker from reacting to the `input` keyup events. The handler for input keyup must only be the parent because daterangepicker does not have access to both the start and end date inputs. As a consequence of not having access to both inputs, the daterangepicker always sets the end date to the start date when a date input is modified. **Steps to reproduce:** - Go to the event app and open a record - Click on an input of the date range picker, and th
Original PR description
This commit deactivates the daterangepicker from reacting to the `input` keyup events. The handler for input keyup must only be the parent because daterangepicker does not have access to both the start and end date inputs. As a consequence of not having access to both inputs, the daterangepicker always sets the end date to the start date when a date input is modified. **Steps to reproduce:** - Go to the event app and open a record - Click on an input of the date range picker, and the picker opens - Move the cursor in the input with the keyboard (right or left arrow) - The picker loses the range **Current behavior:** The picker sets the end date to the start date whenever there is an onKeyup event on the input. **Expected behavior:** The picker should not reset the end date when there is an onKeyup event on the input." ticket-id: 3198864 Forward-Port-Of: odoo/odoo#115666
before this commit, from the function action_validate the function _original_records is called twice to assign the value to original_records variable. after this commit, redundant function calling will be deleted. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#110746
Original PR description
before this commit, from the function action_validate the function _original_records is called twice to assign the value to original_records variable. after this commit, redundant function calling will be deleted. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#110746
They dates from < 2027 and are quite outdated. Favour the nl translation instead. n_BE is not on Transifex so it was not possible to correct bad translations. Forward-Port-Of: odoo/odoo#115798
Original PR description
They dates from < 2027 and are quite outdated. Favour the nl translation instead. n_BE is not on Transifex so it was not possible to correct bad translations. Forward-Port-Of: odoo/odoo#115798
**TO REPRODUCE** - open contacts - open a contact with a picture (for ex, douglas fletcher) - change the picture => new picture is displayed - click on cloud icon to force save => new picture is displayed - repeat: After repeating, the old picture will be displayed. **SOLUTION** Before this change, `getUrl` is bound to the rendering context instead of the component and it will write to the rendering context. This is introduced in this commit: https://github.com/odoo/owl/commit/df5
Original PR description
**TO REPRODUCE** - open contacts - open a contact with a picture (for ex, douglas fletcher) - change the picture => new picture is displayed - click on cloud icon to force save => new picture is…
**TO REPRODUCE** - open contacts - open a contact with a picture (for ex, douglas fletcher) - change the picture => new picture is displayed - click on cloud icon to force save => new picture is displayed - repeat: After repeating, the old picture will be displayed. **SOLUTION** Before this change, `getUrl` is bound to the rendering context instead of the component and it will write to the rendering context. This is introduced in this commit: https://github.com/odoo/owl/commit/df59ec49aefce2e0913fdc1792d42b9680fb28b6 The following excerpt from the mentioned commit explains: "A side-effect of this change is that now the rendering context is no longer the instance of the component by default, but is always an object with the component in its prototype chain." To make sure that `getUrl` is properly bound to the component, we should call it from the `this` of the rendering context. TASK-ID: 3204546 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#115760 Forward-Port-Of: odoo/odoo#115692
while we are creating a new record of the mrp.workorder from the editable list view (mrp_production_workorder_tree_editable_view), we are getting the singleton error, as it is not taking any production record. by applying this commit, it will resolve that singleton error See Traceback in Sentry:-  sentry - 3982694755 --- I confirm I have signed the CLA and r
Original PR description
while we are creating a new record of the mrp.workorder from the editable list view (mrp_production_workorder_tree_editable_view), we are getting the singleton error, as it is not taking any production record. by applying this commit, it will resolve that singleton error See Traceback in Sentry:-  sentry - 3982694755 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#115797
An error during the conversion of the html field to Owl caused the embedded style of the Mail Debug tab to be lost because they were inside a `<link>` element rather than in a `<style>` element. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#115801
Original PR description
An error during the conversion of the html field to Owl caused the embedded style of the Mail Debug tab to be lost because they were inside a `<link>` element rather than in a `<style>` element. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#115801
Before this commit, when over a man2one avatar, on a task project for instance, we don't have any information about the user. Now, a tooltip with the name is shown, note that this was already the behavior in previous versions. task-id = 3148168 Forward-Port-Of: odoo/odoo#115701 Forward-Port-Of: odoo/odoo#115635
Original PR description
Before this commit, when over a man2one avatar, on a task project for instance, we don't have any information about the user. Now, a tooltip with the name is shown, note that this was already the behavior in previous versions. task-id = 3148168 Forward-Port-Of: odoo/odoo#115701 Forward-Port-Of: odoo/odoo#115635
The translation alert banner is an old remaining edit/save feature that is not relevant anymore with the new "always edit" and the "save when leave" features. task-id: 3232795 Forward-Port-Of: odoo/odoo#115725 Forward-Port-Of: odoo/odoo#115315
Original PR description
The translation alert banner is an old remaining edit/save feature that is not relevant anymore with the new "always edit" and the "save when leave" features. task-id: 3232795 Forward-Port-Of: odoo/odoo#115725 Forward-Port-Of: odoo/odoo#115315
## Description The pop-up that shows suggestions when adding a tag on a task is really slow (300~500ms per request on prod). ## Cause `project.tag` has an override of `_name_search()`, which adds a domain of the form ```python ['|', ('task_ids.project_id', '=', project_id), ('project_ids', 'in', project_id)] ``` which is expensive to compute. ## Functional requirements - Suggest tags of the "project" first (those that are on tasks in the same project), then all the rest. - T
Original PR description
## Description The pop-up that shows suggestions when adding a tag on a task is really slow (300~500ms per request on prod). ## Cause `project.tag` has an override of `_name_search()`, which adds a…
## Description
The pop-up that shows suggestions when adding a tag on a task is
really slow (300~500ms per request on prod).
## Cause
`project.tag` has an override of `_name_search()`, which adds a
domain of the form
```python
['|', ('task_ids.project_id', '=', project_id),
('project_ids', 'in', project_id)]
```
which is expensive to compute.
## Functional requirements
- Suggest tags of the "project" first (those that are on tasks in the
same project), then all the rest.
- Tag's name should be sorted alphabetically per result set (tags on tasks of
project first, sorted alphabetically, then all other tags, sorted
alphabetically)
## Solution
Construct a custom query that makes use of CTE and `UNION ALL` to sort
only on a subsets of the tags to speed up. Also `UNION ALL` with a
`LIMIT` is lazy evaluated, so we gain on speed of all tags are comming
from tags on tasks in the current project.
## Affected version
- 16.0
- saas-16.1
- master
---
perf-3209468
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#115790
Forward-Port-Of: odoo/odoo#114318Impacted versions: - 13.0 - 14.0 - 15.0 - 16.0 Description of the issue/feature this PR addresses: A missing of parenthesis around an operator **or** cause a bad evaluation of **False**, allowing to create a stock.valuation.layer with a description containing False. See: [Python Operator Precedence Doc ]( https://docs.python.org/3/reference/expressions.html#operator-precedence) Current behavior before PR: description: Revaluation of False (negative inventory) Desired behavio
Original PR description
Impacted versions: - 13.0 - 14.0 - 15.0 - 16.0 Description of the issue/feature this PR addresses: A missing of parenthesis around an operator **or** cause a bad evaluation of **False**, allowing to create a stock.valuation.layer with a description containing False. See: [Python Operator Precedence Doc ]( https://docs.python.org/3/reference/expressions.html#operator-precedence) Current behavior before PR: description: Revaluation of False (negative inventory) Desired behavior after PR is merged: description: Revaluation of Product Quantity Updated (negative inventory) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#115758 Forward-Port-Of: odoo/odoo#112177
Time Off officer would sometimes get an AccessError when requesting leaves for many employees. opw-3220920 Forward-Port-Of: odoo/odoo#115835 Forward-Port-Of: odoo/odoo#114778
Original PR description
Time Off officer would sometimes get an AccessError when requesting leaves for many employees. opw-3220920 Forward-Port-Of: odoo/odoo#115835 Forward-Port-Of: odoo/odoo#114778
- Steps to reproduce: - Install Employees App Configuration - Got to the Employees > Configuration > Activity Planning > Set the On/Offboarding Plans - Create Test Employee With No Catch - Click on Launch Plan action - Check the Warning in Launch Plan Wizard When employee's coach or manager empty then warning is appeared coach's/manager's user is not set.In this commit we have shown in the warning that the coach/manager is not set. task-3193218 F
Original PR description
- Steps to reproduce:
- Install Employees App Configuration
- Got to the Employees > Configuration > Activity Planning > Set the On/Offboarding Plans
- Create Test Employee With No Catch
- Click on Launch Plan action
- Check the Warning in Launch Plan Wizard
When employee's coach or manager empty then warning is appeared coach's/manager's
user is not set.In this commit we have shown in the warning that the coach/manager
is not set.
task-3193218
Forward-Port-Of: odoo/odoo#112980Bug === When the from_filter of an outgoing mail server contains a domain (e.g. company.com), and when the system parameter "mail.default.from" is a full email address, with a different domain name (e.g. notification@example.com) we concatenate both value which produce an invalid email (e.g. notification@example.com@company.com). Instead, we always give the priority to the from_filter, and fallback on "noreply" for the local part when needed. Task-3230917 Forward-Port-Of: odoo/odoo#1151
Original PR description
Bug === When the from_filter of an outgoing mail server contains a domain (e.g. company.com), and when the system parameter "mail.default.from" is a full email address, with a different domain name (e.g. notification@example.com) we concatenate both value which produce an invalid email (e.g. notification@example.com@company.com). Instead, we always give the priority to the from_filter, and fallback on "noreply" for the local part when needed. Task-3230917 Forward-Port-Of: odoo/odoo#115138
Steps to reproduce: - Go to a website page (edit mode) > Duplicate the footer (or any snippet with a Social Media block). - Save > Traceback. Starting from [1], a `dbSocialValues` variable was used to update the "Social Media" DB links for the current website (on save). These URL values are fetched from database (see: `_fetchSocialMedia()`) to "compute the widget state" and when the snippet is dropped (`onBuilt()`). The specific case of "snippet clone" will lead to a situation wh
Original PR description
Steps to reproduce: - Go to a website page (edit mode) > Duplicate the footer (or any snippet with a Social Media block). - Save > Traceback. Starting from [1], a `dbSocialValues` variable was used to update the "Social Media" DB links for the current website (on save). These URL values are fetched from database (see: `_fetchSocialMedia()`) to "compute the widget state" and when the snippet is dropped (`onBuilt()`). The specific case of "snippet clone" will lead to a situation where the editor is created with an `dbSocialValues === undefined`, leading to trigger the website `write` method with an empty update value... Remark: The "save" works correctly after calling `_computeWidgetState()` The goal of this commit is to simply prevent triggering the `write` update on `clanForSave()` when `dbSocialValues` is `undefined`. [1]: https://github.com/odoo/odoo/commit/f243bcbafb9291d94840795951c8fd51cab0cae1 opw-3204862 Forward-Port-Of: odoo/odoo#115109
Steps to reproduce: -Enable multistep routes for manufacturing -create a MO for 50 products -In internal transfers from Stock to Pre-production validate part of the transfer (20 units) and create a back order for the remaining qty (30 units) -create and validate another pertail transfer (3 units)with a back order for the remaining quantity (27 units) -create a return for the last validated transfers Bug: the default qty for the return is set to -20 where it should be 3 this commit[1
Original PR description
Steps to reproduce: -Enable multistep routes for manufacturing -create a MO for 50 products -In internal transfers from Stock to Pre-production validate part of the transfer (20 units) and create a back order for the remaining qty (30 units) -create and validate another pertail transfer (3 units)with a back order for the remaining quantity (27 units) -create a return for the last validated transfers Bug: the default qty for the return is set to -20 where it should be 3 this commit[1] deducts the previous transfers from the returned amount Fix: only deduct returns from current transfer opw-3104699 [1]:https://github.com/odoo/odoo/commit/7b08f0ae0a39e8f575b21e744de16264b6365704 Forward-Port-Of: odoo/odoo#115763 Forward-Port-Of: odoo/odoo#115110
If the method were called on several new questions from different surveys at the same time (can it happen?), allowed_triggering_question_ids would include questions from all surveys for each of them. A unit test of the method is also included. Introduced in b1d18562. Task-3226408 Forward-Port-Of: odoo/odoo#114965
Original PR description
If the method were called on several new questions from different surveys at the same time (can it happen?), allowed_triggering_question_ids would include questions from all surveys for each of them. A unit test of the method is also included. Introduced in b1d18562. Task-3226408 Forward-Port-Of: odoo/odoo#114965
Steps to reproduce the bug: Here are aliases for the used contacts: - A: Azure Interior - B: Gemini Furniture - C: Gemini Furniture, Edwin Hansen - D: (delivery address for Edwin Hansen) 1. Login on a runbot. 2. Set VAT of A and B to different values. 3. Open C, and create a delivery address: D 4. Check: VAT of D = VAT of B 5. Change the related company of C from B to A. Bug: The VAT of C = VAT of A, however VAT of D did not change. When syncing the commercial fields of a
Original PR description
Steps to reproduce the bug:
Here are aliases for the used contacts:
- A: Azure Interior
- B: Gemini Furniture
- C: Gemini Furniture, Edwin Hansen
- D: (delivery address for Edwin Hansen)
1. Login on a runbot.
2. Set VAT of A and B to different values.
3. Open C, and create a delivery address: D
4. Check: VAT of D = VAT of B
5. Change the related company of C from B to A.
Bug:
The VAT of C = VAT of A, however VAT of D did not change.
When syncing the commercial fields of a partner, we also sync his childs.
PS: Due to function _compute_commercial_partner, the commercial partner is always updated for all the childs.
So the condition child.commercial_partner_id != self.commercial_partner_id is never satisfied in function _children_sync and the commercial fields were never updated.
opw:3111493
Forward-Port-Of: odoo/odoo#110866
Forward-Port-Of: odoo/odoo#109074Steps to reproduce: - open Discuss app with "General" as active thread - open call settings in the inspector - open a mailbox as active thread Crash: ``` Cannot read showOnlyVideo of undefined ``` This happens because discuss has a single thread view that is shared for any selected thread. However, the call settings menu only makes sense for thread that have call feature, which applies for only channels. Mailboxes should not have any call settings menu. Description of the issue/fe
Original PR description
Steps to reproduce: - open Discuss app with "General" as active thread - open call settings in the inspector - open a mailbox as active thread Crash: ``` Cannot read showOnlyVideo of undefined ``` This happens because discuss has a single thread view that is shared for any selected thread. However, the call settings menu only makes sense for thread that have call feature, which applies for only channels. Mailboxes should not have any call settings menu. 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#115646 Forward-Port-Of: odoo/odoo#115537
We created an index in the mixin, but the `init` was never called as there was a missing `super` in `account_move_line`. We also remove the index in `sales_project`, as it now is done in the mixin (and we don't want different names for it). 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#115887
Original PR description
We created an index in the mixin, but the `init` was never called as there was a missing `super` in `account_move_line`. We also remove the index in `sales_project`, as it now is done in the mixin (and we don't want different names for it). 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#115887
Steps to reproduce: - take a project; - change the visibility to allow sharing; - click on "SHARE EDITABLE"; - share the project with a portal user; - login as portal; - try to open a project task. Remark: the problem does not occur for all tasks. Issue: A traceback appears. Cause: Error occurs because: `return (token and record and consteq(record[token_field], token))` compare two values with different type. - `token` is equal to `'null'` - `record[token_field]` is equal to `Fal
Original PR description
Steps to reproduce: - take a project; - change the visibility to allow sharing; - click on "SHARE EDITABLE"; - share the project with a portal user; - login as portal; - try to open a project task.…
Steps to reproduce: - take a project; - change the visibility to allow sharing; - click on "SHARE EDITABLE"; - share the project with a portal user; - login as portal; - try to open a project task. Remark: the problem does not occur for all tasks. Issue: A traceback appears. Cause: Error occurs because: `return (token and record and consteq(record[token_field], token))` compare two values with different type. - `token` is equal to `'null'` - `record[token_field]` is equal to `False` In the code: `consteq = hmac_lib.compare_digest` > `hmac.compare_digest(a, b)` Return `a == b`. This function uses an approach designed to prevent timing analysis by avoiding content-based short circuiting behaviour, making it appropriate for cryptography. a and b must both be of the same type: either str (ASCII only, as e.g. returned by HMAC.hexdigest()), or a bytes-like object. [source](https://docs.python.org/3/library/hmac.html#hmac.compare_digest) The source of the problem is upstream to this comparison. Indeed, we first test if we have a token. As the value of the token is `'null'`, we pass the condition. Solution: It is necessary to have a token equal to `False` if the task has not token. Therefore, whatever the value of the token (token value or `False`), we have to update the token. opw-3217490 Forward-Port-Of: odoo/odoo#115151
First issue =========== Steps to reproduce ------------------ - Install web_studio,sale_management - Settings > Sales > Pricelists - Set the value to Multiple prices per product - Home > Sales > Product > Pricelists - Click on the first record - The x2many list view is contains the following fields: `Products | Variants | ...` - Open studio - The view changes to `Applicable On | Minimum Quantity | ...` Cause of the issue ------------------ When using studio, nodes with miss
Original PR description
First issue =========== Steps to reproduce ------------------ - Install web_studio,sale_management - Settings > Sales > Pricelists - Set the value to Multiple prices per product - Home > Sales >…
First issue
===========
Steps to reproduce
------------------
- Install web_studio,sale_management
- Settings > Sales > Pricelists
- Set the value to Multiple prices per product
- Home > Sales > Product > Pricelists
- Click on the first record
- The x2many list view is contains the following fields: `Products | Variants | ...`
- Open studio
- The view changes to `Applicable On | Minimum Quantity | ...`
Cause of the issue
------------------
When using studio, nodes with missing groups have an invisible modifiers instead of being removed from the arch. This means that the subarch is always the last one.
```xml
<tree
string="Pricelist Rules"
editable="bottom"
groups="!product.group_sale_pricelist"
studio_groups="[]"
>
Products
Variants
</tree>
<tree
string="Pricelist Rules"
modifiers='{"invisible": true}'
groups="product.group_sale_pricelist"
studio_groups='[{"id": 17, "name": "Adv… Advanced Pricelists"}]'
>
Applicable On
Minimum Quantity
</tree>
```
Solution
--------
Remove invisible subviews from the arch
Second Issue
============
Once the first issue has been fixed, we have another one
Steps to reproduce
------------------
- Home > Sales > Product > Pricelists
- Click on the first record
- Open studio
- `Single sub-view arch not found for xpath: /form[1]/sheet[1]/notebook[1]/page[1]/field[1]/tree`
Cause of the issue
------------------
Since there are multiple subviews, there is more than a single match
Solution
--------
The function `getSubArch` should also ignore invisible subviews. We then need to keep track the correct subarch position in order to use the correct xpath.
We use this position to set the subview_xpath accordingly. Finally, we also need to update the position inside the xpath_info
opw-3145355
Forward-Port-Of: odoo/enterprise#38417
Forward-Port-Of: odoo/enterprise#38036The uploading cron could sometimes crash due to a concurrent update error. In that case, the other documents awaiting upload wouldn't be sent to the extraction server before the next cron execution, leading to a long delay for the user. The previous code wasn't handling the error properly as the savepoint wasn't rollbacked in that case. Ticket #3207721 Forward-Port-Of: odoo/enterprise#38298 Forward-Port-Of: odoo/enterprise#38199
Original PR description
The uploading cron could sometimes crash due to a concurrent update error. In that case, the other documents awaiting upload wouldn't be sent to the extraction server before the next cron execution, leading to a long delay for the user. The previous code wasn't handling the error properly as the savepoint wasn't rollbacked in that case. Ticket #3207721 Forward-Port-Of: odoo/enterprise#38298 Forward-Port-Of: odoo/enterprise#38199
In the "MRR/NRR Pipeline Revenue Report (Monthly)" spreadsheet template, Some pivot measures are not loaded. The measures in the pivot definition are "recurring_revenue_monthly", "recurring_revenue_monthly_prorated", "expected_revenue" and "prorated_revenue". But there's only two of them in the pivot context ("expected_revenue" and "prorated_revenue") It turns out the context has priority over search params[1] This redundant measures should probably be cleaned. I'm not sure if we rea
Original PR description
In the "MRR/NRR Pipeline Revenue Report (Monthly)" spreadsheet template, Some pivot measures are not loaded. The measures in the pivot definition are "recurring_revenue_monthly",…
In the "MRR/NRR Pipeline Revenue Report (Monthly)" spreadsheet template, Some pivot measures are not loaded.
The measures in the pivot definition are "recurring_revenue_monthly", "recurring_revenue_monthly_prorated", "expected_revenue" and "prorated_revenue".
But there's only two of them in the pivot context ("expected_revenue" and "prorated_revenue")
It turns out the context has priority over search params[1]
This redundant measures should probably be cleaned. I'm not sure if we really need the ones in the context (maybe for the "See records" feature?). As a bug fix, for minimum risk, this commit simply adds the missing measures in the context.
Note: this issue was reported by XPL while writing the user documentation. It shows this template was never used by anyone. That's why I'm only fixing it in 16.0 and not before. I don't want a huge diffs everywhere. (in master, those json files should be prettified)
[1] https://github.com/odoo/odoo/blob/273b99adc34d478d62d107040eae1db3ca883f6e/addons/web/static/src/views/pivot/pivot_model.js#L686
Forward-Port-Of: odoo/enterprise#38305The consequence of the following two commits: 4ab33d300006215146ddbf7a19e754f9470f0966 9e677ea115c1494d029513428e3919f54d24b27f Make the solution use the local language 'en_US'. Unfortunately, some databases do not have this language installed. The goal is to find the date of the check in. For example, for an attendance issued in the timezone 'Brussel/Europe' on February 1st, if the only language installed in the database is French the function `_read_group` with `groupby=[..., 'check_
Original PR description
The consequence of the following two commits: 4ab33d300006215146ddbf7a19e754f9470f0966 9e677ea115c1494d029513428e3919f54d24b27f Make the solution use the local language 'en_US'. Unfortunately, some…
The consequence of the following two commits:
4ab33d300006215146ddbf7a19e754f9470f0966
9e677ea115c1494d029513428e3919f54d24b27f
Make the solution use the local language 'en_US'.
Unfortunately, some databases do not have this language installed.
The goal is to find the date of the check in.
For example, for an attendance issued in the timezone 'Brussel/Europe' on February 1st, if the only language installed in the database is French the function `_read_group` with `groupby=[..., 'check_in:day']` will return:
```py
check_in:day': '01 févr. 2023'
'__range': { 'check_in:day': { 'from': '2023-01-31 23:00:00', 'to': '2023-02-01 23:00:00'}}
```
As we cannot parse the date, we need to find '2023-02-01' with '2023-01-31 23:00:00'.
It is therefore necessary to use the timezone of the employee who encoded the attendance.
Important remark:
The strong assumption is that the employee himself encodes his attendances.
If this is not the case, it is a direct manager who is in the same timezone.
opw-3182713
Forward-Port-Of: odoo/enterprise#38006Before this PR the belgian BS wasn't balanced since an account was missing in the BS (the account 497 was present in the COA but not in the BS). By adding the account the balance sheet is now correctly balanced. Task-id: 3041738 Forward-Port-Of: odoo/enterprise#38111
Original PR description
Before this PR the belgian BS wasn't balanced since an account was missing in the BS (the account 497 was present in the COA but not in the BS). By adding the account the balance sheet is now correctly balanced. Task-id: 3041738 Forward-Port-Of: odoo/enterprise#38111
Steps to reproduce: Use a normal user without admin permission to access the Time Off app or Employees app Current behaviour: Access Error shown. Expected behaviour: Should be able to access the app without any issue. Explaning: HK employees have a new way to calculate the work intervals batch. However they don't have permission to use work_entry_type_id data. Therefore we need to use sudo to compute the leave_attendance_intervals. X-original-commit: 45321a2 Forward-Port-Of: odo
Original PR description
Steps to reproduce: Use a normal user without admin permission to access the Time Off app or Employees app Current behaviour: Access Error shown. Expected behaviour: Should be able to access the app without any issue. Explaning: HK employees have a new way to calculate the work intervals batch. However they don't have permission to use work_entry_type_id data. Therefore we need to use sudo to compute the leave_attendance_intervals. X-original-commit: 45321a2 Forward-Port-Of: odoo/enterprise#38318
task - 3087873 Forward-Port-Of: odoo/enterprise#37537
Original PR description
task - 3087873 Forward-Port-Of: odoo/enterprise#37537
Steps to reproduce: - create a product; - check Recurring; - select Storable Product; - save (an error message appears); - uncheck Recurring; - save. Issue: An error message appears when the data in the form is correct. Cause: The product type is reset to False. Solution: The product type must not be modified to not trigger the error. opw-3171505 Forward-Port-Of: odoo/enterprise#38019
Original PR description
Steps to reproduce: - create a product; - check Recurring; - select Storable Product; - save (an error message appears); - uncheck Recurring; - save. Issue: An error message appears when the data in the form is correct. Cause: The product type is reset to False. Solution: The product type must not be modified to not trigger the error. opw-3171505 Forward-Port-Of: odoo/enterprise#38019
task - 3203838 Forward-Port-Of: odoo/enterprise#37749
Original PR description
task - 3203838 Forward-Port-Of: odoo/enterprise#37749
Before this commit method to get recurring field was not update with recent refactoring of recurrence feature. This commit update that method to make worksheet template field recurring field. Forward-Port-Of: odoo/enterprise#38337
Original PR description
Before this commit method to get recurring field was not update with recent refactoring of recurrence feature. This commit update that method to make worksheet template field recurring field. Forward-Port-Of: odoo/enterprise#38337
I don't like receiving a screenshot of the document UUID, there is no excuse now. Forward-Port-Of: odoo/enterprise#38300
Original PR description
I don't like receiving a screenshot of the document UUID, there is no excuse now. Forward-Port-Of: odoo/enterprise#38300
Use the same color to visualise time off type in the gantt view than the one used in the calendar view. opw-3199376 Forward-Port-Of: odoo/enterprise#37956
Original PR description
Use the same color to visualise time off type in the gantt view than the one used in the calendar view. opw-3199376 Forward-Port-Of: odoo/enterprise#37956