Wednesday, April 13, 2022
31 changes · master
Enhancements to existing features
The mail app's message and chat window logic was reorganized so key actions live in shared data models rather than screen components. This internal improvement should make future changes easier and reduce the risk of fragile behavior, without introducing a major user-facing change.
Original PR description
This commit moves some handler methods from components to models, as a step closer to having most of business code in models. Having business code in models is desirable so that the code is much more maintainable: easier to change and more robust code. Task-2579306
This update standardizes a shorthand used by Odoo developers to express optional search filters. It makes common filtering rules easier to write and maintain, reducing complexity in core code without changing expected business behavior.
Original PR description
Previous to this PR, [we had only 1 short-circuit operator: `=?`](https://github.com/odoo/odoo/blob/44029495bc4f85c9f99b16dbab0a49c6ba0f19f9/odoo/osv/expression.py#L1028-L1035). This PR formalizes…
Previous to this PR, [we had only 1 short-circuit operator: `=?`](https://github.com/odoo/odoo/blob/44029495bc4f85c9f99b16dbab0a49c6ba0f19f9/odoo/osv/expression.py#L1028-L1035).
This PR formalizes the concept and applies it to all existing operators, also introducing a left short-circuit equivalent (`?=`).
```
Short-circuit operators are:
<term_operator>? right is false or left <term_operator> right
?<term_operator> left is false or left <term_operator> right
Some examples of short-circuit operators:
=? right = false or left = right
!=? right = false or left != right
>? right = false or left > right
<? right = false or left < right
>=? right = false or left >= right
<=? right = false or left <= right
in? right = false or left in right
not in? right = false or left not in right
?= left = false or left = right
?!= left = false or left != right
?> left = false or left > right
?< left = false or left < right
?>= left = false or left >= right
?<= left = false or left <= right
?in left = false or left in right
?not in left = false or left not in right
```
Using short-circuit operators enables the simplification of some domains like, for example, probably the most common one in Odoo:
`[('|', ('company_id', '=', False), ('company_id', 'in', company_ids)]`
With short-circuit operators:
`[('company_id', '?in', company_ids)]`
Here's another example with a datetime field:
`['|', ('deadline', '=', False), ('deadline', '<=', fields.Datetime.now())]`
`[('deadline', '?<=', fields.Datetime.now())]`
--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThe mail composer was simplified by removing an outdated internal content-reading method. This makes the messaging code easier to maintain and helps reduce future issues without changing the user experience.
Original PR description
Task-2579306
This update simplifies the mail message composer by removing an unnecessary internal text selection helper. It helps keep the messaging code easier to maintain without changing how users write or send messages.
Original PR description
Task-2579306
The mail composer has been updated to handle Enter key actions through a dedicated composer view. This makes message writing behavior easier to maintain and helps ensure a smoother, more consistent user experience when composing messages.
Original PR description
Task-2579306
The mail app now handles the Enter key in the message composer through a clearer shared view layer. This should make composer behavior easier to maintain and help keep message-entry interactions consistent across the application.
Original PR description
Task-2579306
The Discuss app is being updated to better handle the action for creating a new channel on mobile. This should make the mobile messaging experience more consistent and easier to maintain as the interface evolves.
Original PR description
Task-2579306
The Discuss mobile interface now has a clearer internal handling for selecting mailbox items. This improves the reliability and maintainability of the mobile messaging experience, helping users navigate conversations more smoothly.
Original PR description
Task-2579306
Discuss is being updated to better manage the quick search input within the messaging interface. This helps prepare the mail app for smoother navigation and more reliable search interactions in Discuss.
Original PR description
Task-2579306
This update improves how the Discuss app handles the action to start a meeting from the sidebar. It helps keep the meeting-start flow better organized and easier to maintain, supporting a smoother collaboration experience for users.
Original PR description
Task-2579306
The mail app now handles follow-button clicks through the message thread itself, making follow and unfollow actions more consistent. This improves reliability and maintainability of the user experience around following conversations.
Original PR description
Task-2579306
The mail app now handles the unfollow action through the conversation itself, making follower controls more consistent. This should make maintaining and improving the follow/unfollow experience easier while keeping the user-facing behavior stable.
Original PR description
Task-2579306
The mail app’s internal message and discussion handling has been reorganized so more business logic sits in shared models instead of screen components. This should make future changes easier, reduce duplication, and improve long-term reliability without introducing major visible changes for users.
Original PR description
This commit moves some handler methods from components to models, as a step closer to having most of business code in models. Having business code in models is desirable so that the code is much more maintainable: easier to change and more robust code. Task-2579306
Payslip batches now skip unnecessary checks when expense-related payroll data does not require them. This reduces extra database work during batch creation, helping payroll processing run more efficiently without changing the user workflow.
Original PR description
Filters out 2 queries when creating payslips if they are not necessary.
Resolved issues and error corrections
This fixes a display issue in sales email templates where repeated items could use the same style instead of alternating as intended. Sales communications should now appear more clearly formatted and visually consistent for recipients.
Original PR description
Before this commit At each iteration, the `loop_cycle_number` was reset to 0. This caused the cycle condition to always be the same. After this commit The cycle condition will properly make the style cycle. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Miscellaneous changes
-- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#88443
Original PR description
-- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#88443
This update fixes two small issues in Planning: an error that could appear when publishing shifts for an employee without an email, and a misplaced tooltip in the Planning Gantt view. These fixes make the publishing flow more reliable and improve guidance during the planning tour.
Original PR description
PURPOSE
some bugs fixes for planning
- fixed traceback when clicking on the field
steps to produce the issue:
gantt view > publish > create an employee without an email >
publish and send > clicking on the manager field
- fixed tooltip indication pointing to wrong place
in planning gantt view
task-2790017# Steps to reproduce: Decimal Accuracy - Product Price = 2 - create a product `alc 50%` with BOM (10 unites = 1 unit Water [cost=0.14]; 1 unit Alc [cost=0.08]) - Set `quantity on hands` = 10,000 - Trigger `Compute Price from BoM` -> In Reporting > Inventory Valuation; click on the layer; in Other Info: You will see "Product value manually modified (from 0.0 to 0.022000000000000002)" => It can cause computing mistakes as we changed the costs # Cause: The value is calculated as the
Original PR description
# Steps to reproduce: Decimal Accuracy - Product Price = 2 - create a product `alc 50%` with BOM (10 unites = 1 unit Water [cost=0.14]; 1 unit Alc [cost=0.08]) - Set `quantity on hands` = 10,000 -…
# Steps to reproduce: Decimal Accuracy - Product Price = 2 - create a product `alc 50%` with BOM (10 unites = 1 unit Water [cost=0.14]; 1 unit Alc [cost=0.08]) - Set `quantity on hands` = 10,000 - Trigger `Compute Price from BoM` -> In Reporting > Inventory Valuation; click on the layer; in Other Info: You will see "Product value manually modified (from 0.0 to 0.022000000000000002)" => It can cause computing mistakes as we changed the costs # Cause: The value is calculated as the difference between the New Price (cost) and and the current Product Standard Price (cost). But, on one hand the Product Standard Price is rounded to the number of digits defined in the Decimal Accuracy for the Product Price. On the other hand, the New Price is used as is with no rounding. If we add an extra step and modify the cost of the Water to 0.45 and trigger again the `Compute Price from BoM` we will have: "Product value manually modified (from 0.02 to 0.053000000000000005)" # Solution: Use for the New Price the same rounding precision as we use for the Standard Price. # Example (based on the test): ## Set up #### BoM: Alc. 50% ``` Product quantity_needed Water 0.1 Alc. 100% 0.1 ``` ## Stage1: Init #### Products ``` Product price_unit Water 0.14 Alc. 100% 0.08 ``` ___ #### Stock Valuation ``` Cost/unit of Alc. 50%: 0.022 => 0.02 (standard_price is rounded) Set Quantity on Hand: 10,000 ``` ``` Layer Computation Total #1 0.02 * 10,000 200 Total 200 200 ``` => The standard_price is rounded to the second digit when intialized ## Stage 2: Increase price of water #### Products ``` Product price_unit Water 0.45 Alc. 100% 0.08 ``` ____ #### Stock Valuation ``` Cost/unit of Alc. 50%: 0.053 Quantity on Hand: 10,000 ``` ``` Without Fix Layer Computation Total #1 0.02 * 10,000 200 #2 (0.053-0.02) * 10,000 330 Total 200 + 330 530 ____ With Fix Layer Computation Total #1 0.02 * 10,000 200 #2 (0.05-0.02) * 10, 000 300 Total 200 + 300 500 ``` => Without fix, the value is computed with the rounded standard_price and the not rounded new_price. => With fix, the new_price is rounded the same way as the standard_price opw-2724975 Forward-Port-Of: odoo/odoo#87600
Since [1] when the fuzzy search was introduced, the candidate words used for the fuzzy matching were split on non-'\w' (all non alphanumeric characters + underscore). This commit adds '-' (hyphen) to the list of characters that should be considered part of the same word. Steps to reproduce: - Specify a product with name 'micro-vis' - search for 'micro-vis' or 'microvis' => Was not returning any match => Now returns fuzzy match even for 'micro-vs' opw-2801704 [1]: https://githu
Original PR description
Since [1] when the fuzzy search was introduced, the candidate words used for the fuzzy matching were split on non-'\w' (all non alphanumeric characters + underscore). This commit adds '-' (hyphen) to the list of characters that should be considered part of the same word. Steps to reproduce: - Specify a product with name 'micro-vis' - search for 'micro-vis' or 'microvis' => Was not returning any match => Now returns fuzzy match even for 'micro-vs' opw-2801704 [1]: https://github.com/odoo/odoo/commit/c6ba756e4b4704089d02434871788a82d90cb195 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#87482
**Steps to follow** - Go to Accounting > Accounting > Sales (account.move.line model) - Remove any existing group by - Group by Products - Select multiples lines of the same product - Try to modify the account of the select line -> `this.localData[value] is undefined **Cause of the issue** When grouping by a field not in the view, `list.__data` contains the groupedBy field value because we fetched the group through a web_read_group **Solution** Filter out a
Original PR description
**Steps to follow** - Go to Accounting > Accounting > Sales (account.move.line model) - Remove any existing group by - Group by Products - Select multiples lines of the same product - Try to modify the account of the select line -> `this.localData[value] is undefined **Cause of the issue** When grouping by a field not in the view, `list.__data` contains the groupedBy field value because we fetched the group through a web_read_group **Solution** Filter out absent fields before creating the group datapoint opw-2784995 Forward-Port-Of: odoo/odoo#88579 Forward-Port-Of: odoo/odoo#88032
Task-2812497 accidentaly removed some CSS rules, causing the dialog not to be centered properly. This commit put the rules back. Forward-Port-Of: odoo/odoo#88451
Original PR description
Task-2812497 accidentaly removed some CSS rules, causing the dialog not to be centered properly. This commit put the rules back. Forward-Port-Of: odoo/odoo#88451
Currently, the event sponsor ordering on the website is non-deterministic as it uses a non-ordered dictionary to accumulate items, which then dictates the order of display. We fix that issue by using a OrderedDict that will correctly retain the order. In addition, we force the sorting of sponsors based on their event.sponsor.type's sequence first and then based on their own sequence. The '_order' of event.sponsor is currently 'sequence, sponsor_type_id' which seems wrong but has to
Original PR description
Currently, the event sponsor ordering on the website is non-deterministic as it uses a non-ordered dictionary to accumulate items, which then dictates the order of display. We fix that issue by using…
Currently, the event sponsor ordering on the website is non-deterministic as it uses a non-ordered dictionary to accumulate items, which then dictates the order of display. We fix that issue by using a OrderedDict that will correctly retain the order. In addition, we force the sorting of sponsors based on their event.sponsor.type's sequence first and then based on their own sequence. The '_order' of event.sponsor is currently 'sequence, sponsor_type_id' which seems wrong but has to stay that way in order to avoid backend issues. Indeed, the backend and the "handle widget" do not have the capability to sort on multiple levels as we would need here (sponsor type sequence, then sponsor sequence). To completely fix this issue, we would need to: - Store the sponsor.type's sequence field on the sponsor (related stored) - Modify the _order to be sponsor_type_sequence, sequence - Only allow people to sort event.sponsors within a single category at a time Those changes would not be doable on a stable branch, hence why we use a local sorting when displaying sponsors on the website. Task-2818538 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#88584 Forward-Port-Of: odoo/odoo#88450
For now `hr_timesheet_graphview` doesn't work with dashboard because `board` is still in legacy and `hr_timesheet_graphview` in owl. So we have to create a legacy version of it to adapt it to dashboard. Similar fix: https://github.com/odoo/odoo/pull/86571/files opw-2793729 Forward-Port-Of: odoo/odoo#88385
Original PR description
For now `hr_timesheet_graphview` doesn't work with dashboard because `board` is still in legacy and `hr_timesheet_graphview` in owl. So we have to create a legacy version of it to adapt it to dashboard. Similar fix: https://github.com/odoo/odoo/pull/86571/files opw-2793729 Forward-Port-Of: odoo/odoo#88385
A mechanism is provided by the OdooEditor to circumvent certain problems while editing links. More specifically, editable zones are patched when editing a link. This avoids the cursor ending up outside the link whenever the link tag is emptied. However, the mechanism does not check if the link is also in the editable zone before doing so. In translation mode, the editable zones correspond to the individual translation strings. When translating link texts, this means the anchor tag containing
Original PR description
A mechanism is provided by the OdooEditor to circumvent certain problems while editing links. More specifically, editable zones are patched when editing a link. This avoids the cursor ending up outside the link whenever the link tag is emptied. However, the mechanism does not check if the link is also in the editable zone before doing so. In translation mode, the editable zones correspond to the individual translation strings. When translating link texts, this means the anchor tag containing the translation string is outside the editable zone. The patching mechanism still applies, resulting in the anchor tag becoming editable as well. This causes problems while translating links, for example `oDeleteBackward` commands are being rolled back. Checking if the anchor tag is inside the editable zone resolves the problem. Forward-Port-Of: odoo/odoo#87519
Batch of ux fixes. task: 2781002 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#85486
Original PR description
Batch of ux fixes. task: 2781002 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#85486
A field order_id has been introduce on account.analytic.line in https://github.com/odoo/odoo/commit/dc9ef81ab21cbbf232eca1771ab94dd5a54e9345 to allow to group by order This field was introduce as related readonly=False. It has the side effect of modifying the order_id on the sale.order.line each time a timesheet is created and thus trigger computed field that are based on that field. Since the field is only declared for a group by it's pointless to make it modifiable, it will save a
Original PR description
A field order_id has been introduce on account.analytic.line in https://github.com/odoo/odoo/commit/dc9ef81ab21cbbf232eca1771ab94dd5a54e9345 to allow to group by order This field was introduce as related readonly=False. It has the side effect of modifying the order_id on the sale.order.line each time a timesheet is created and thus trigger computed field that are based on that field. Since the field is only declared for a group by it's pointless to make it modifiable, it will save a lot a useless computation and avoid some issue with computed field wrongly triggered -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#88576 Forward-Port-Of: odoo/odoo#88524
When creating a global time off in one resource.calendar A , it will be propagated on any new resource.calendar B. However the reverse is not true, if I delete the global time off in calendar A it will not be deleted in calendar B. During the work entry generation this is not taken into account, a contract using calendar A will generate leave work entries because of the global time off in calendar B. This is due to a change in PR odoo/enterprise#15091. The domain is now correct and wil
Original PR description
When creating a global time off in one resource.calendar A , it will be propagated on any new resource.calendar B. However the reverse is not true, if I delete the global time off in calendar A it will not be deleted in calendar B. During the work entry generation this is not taken into account, a contract using calendar A will generate leave work entries because of the global time off in calendar B. This is due to a change in PR odoo/enterprise#15091. The domain is now correct and will only fetch the right leaves. TaskId-2627378 Forward-Port-Of: odoo/odoo#88669 Forward-Port-Of: odoo/odoo#86738
Steps to reproduce: - Install eCommerce module - Select company A and set only one pricelist with: - company = company A - website = website of company A - Select company B and set multiple pricelist. - Switch to company B - Archive a pricelist Issue: Error: "With this action, "Website of company A" website would not have any pricelist available". Solution: Use sudo() when searching websites to don't use multi-company compliant ir.rule `product_pr
Original PR description
Steps to reproduce:
- Install eCommerce module
- Select company A and set only one pricelist with:
- company = company A
- website = website of company A
- Select company B and set multiple pricelist.
- Switch to company B
- Archive a pricelist
Issue:
Error: "With this action, "Website of company A" website would not
have any pricelist available".
Solution:
Use sudo() when searching websites to don't use multi-company
compliant ir.rule `product_pricelist_comp_rule` (in website_sale) when
getting pricelist_ids (and therefore allow checking all pricelists for
all websites in all companies)
opw-2759069
Forward-Port-Of: odoo/odoo#88597
Forward-Port-Of: odoo/odoo#85544The representative node is at the wrong place. This has been introduced by https://github.com/odoo/enterprise/commit/95d8a49162da9a7608180d1748996a68d85c9894 Before this commit: The xml file is rejected by intervat After this commit: The xml file is accepted by intervat enterprise-pr: ticket: 2822476 Forward-Port-Of: odoo/enterprise#26146
Original PR description
The representative node is at the wrong place. This has been introduced by https://github.com/odoo/enterprise/commit/95d8a49162da9a7608180d1748996a68d85c9894 Before this commit: The xml file is rejected by intervat After this commit: The xml file is accepted by intervat enterprise-pr: ticket: 2822476 Forward-Port-Of: odoo/enterprise#26146
…port Forward-Port-Of: odoo/enterprise#26118
Original PR description
…port Forward-Port-Of: odoo/enterprise#26118
The behavior of this module was not being tested. Forward-Port-Of: odoo/enterprise#26128 Forward-Port-Of: odoo/enterprise#26070
Original PR description
The behavior of this module was not being tested. Forward-Port-Of: odoo/enterprise#26128 Forward-Port-Of: odoo/enterprise#26070