Thursday, October 20, 2022
19 changes · master
Enhancements to existing features
This update reorganizes how the mail chat window is managed behind the scenes. It should make the chat experience easier to maintain and improve over time without changing day-to-day user workflows.
Original PR description
Task-3004259
The email attachment viewer has been reorganized internally to make the code easier to maintain and evolve. This should not change day-to-day user behavior, but it helps support future improvements with lower risk.
Original PR description
Task-2996277
The mail app’s hidden chat window menu was reorganized so its behavior is handled more consistently behind the scenes. This should make the chat interface easier to maintain and reduce the risk of future issues without changing the visible workflow for users.
Original PR description
Task-3014736
The mail app's hidden chat window menu has been reorganized internally to make it easier to maintain and evolve. This should help future improvements to chat behavior while keeping the current user experience unchanged.
Original PR description
Task-3014736
The mail chat window header was adjusted to pass only the needed conversation record between interface components. This keeps the chat interface easier to maintain and helps reduce the risk of future issues without changing the user experience.
Original PR description
Task-3001202
Point of Sale settings now let businesses choose whether orders paid with electronic payment methods are automatically validated. This gives stores more control over checkout workflows, allowing teams to keep the current fast flow or require manual confirmation when needed.
Original PR description
Actually if the customer pay with a electronic payment method the order is automatically validated. With this commit we add the possibility to activate or not this functionality 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 mail chat window hidden menu was reorganized so its display logic is handled more consistently in the underlying data layer. This is an internal improvement that should make the chat interface easier to maintain without changing how users work with it.
Original PR description
Task-3004253
CRM activity reports now show and allow filtering by the tags linked to each lead, making it easier to analyze activities by customer segment or campaign category. The activity list view is also cleaner, with author avatars shown and descriptions hidden by default to focus on key reporting details.
Original PR description
Allows more granularity on the activity reports by adding a column to the tree view of crm activity reporting. Those are the tags of the lead of the activity. Remove useless 'api' import. Also, make them available in the search bar and default show in the tree view of activities. Improve the view with an avatar widget on the author and default hide on the description. Task-2991375
Settings changes are now applied before users follow related configuration links. This helps ensure the linked setup screens reflect the latest choices and avoids confusion from unsaved settings.
Original PR description
Description of the issue/feature this PR addresses: <b>Taks:</b>https://www.odoo.com/web?#id=1921574&action=333&active_id=131&model=project.task&view_type=form&menu_id=4720 <b>Pad:</b> https://pad.odoo.com/p/r.c30051da9b644dddb13b13758006b911 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
Empty HTML/rich text fields that previously stored invisible blank tags will now be saved as truly empty values. This prevents the system from mistakenly treating blank configuration fields as filled in, reducing confusion and incorrect behavior in related checks.
Original PR description
Description of the issue/feature this PR addresses: If html fields are left empty in configuration it could hapen it has empty tags in the database. If checked if these fields have content this test will return True. To avoid this the tags should be replaced by an empty string before writing to the database. example of unwanted behavior: https://drive.google.com/file/d/1dO_Ur6n3Sgzem0KQ_dXEPRlQkTVaEim8/view Desired behavior after PR is merged: during sanitizing of html fields run a regex over the field to determine if it consists of anpty tags or only whitespaces. In this case return '' instead of the original field. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Odoo now lets certain automatically filled fields keep a user-provided value instead of overwriting it during record creation or updates. This makes sales and accounting workflows more consistent, reducing manual onchange logic while preserving user choices when they intentionally override defaults.
Original PR description
On stored computed fields with `readonly=False`, do not compute the field if a value is passed by write or create method. Instead of ```python fiscal_position =…
On stored computed fields with `readonly=False`, do not compute the field if a value is passed by write or create method.
Instead of
```python
fiscal_position = fields.Many2one('account.fiscal.position')
@api.onchange('partner_id')
def onchange_partner_fiscal_position(self):
self.fiscal_position = self.partner_id.property_account_position
```
we define
```python
fiscal_position = fields.Many2one('account.fiscal.position',
compute='_compute_fiscal_position',
store=True, readonly=False)
@api.depends('partner_id.property_account_position')
def _compute_fiscal_position(self):
for record in self:
record.fiscal_position = record.partner_id.property_account_position
```
So the onchange is defined as a computed field that can be modified by the user.
Behavior
- an onchange triggered on 'partner_id' automatically invalidates 'fiscal_position' and recomputes it
- write({'partner_id': pid}) automatically invalidates 'fiscal_position' and recomputes it
- write({'partner_id': pid, 'fiscal_position': fp}) does not recompute 'fiscal_position'
- create({'partner_id': pid}) automatically computes 'fiscal_position'
- create({'partner_id': pid, 'fiscal_position': fp}) does not recompute 'fiscal_position'
The behavior covers:
- onchange methods: potentially a majority of onchange methods can be expressed as compute methods
- create() and write() behave as if they had executed the onchange methodsCurrency amounts are now shown and understood according to the user's language settings, including symbol placement and spacing. This makes prices and monetary values clearer and more consistent across accounting, sales, point of sale, delivery, lunch, digest, and web screens.
Original PR description
Description of the issue/feature this PR addresses: <b>Task:</b> https://www.odoo.com/web?#id=35636&action=333&active_id=131&model=project.task&view_type=form&menu_id=4720 <b> Pad:</b> https://pad.odoo.com/p/r.11ed19a243459e5cbd148b9c1fe75b4d Current behavior before PR: Desired behavior after PR is merged: -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update standardizes how internal screen events are named and passed between parts of Odoo. It should make the platform easier to maintain and reduce the risk of inconsistent behavior across apps, without introducing major visible changes for everyday users.
Original PR description
Task:https://www.odoo.com/web?debug=1#id=48682&action=333&active_id=133&model=project.task&view_type=form&menu_id=4720 Pad: https://pad.odoo.com/p/r.8490ec0f0b238b75b008b1873aeb8da7 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Odoo now avoids unnecessary price calculations when it only needs to identify which pricelist rule applies. This can improve performance in sales pricing flows without changing the final prices users see.
Original PR description
For the sale scope, we added a new 'pricelist_item_id' field, caching the pricelist rule used for the price_unit and discount computation. This feature uses the new `_get_pricelist_rule` method, which only returns the pricelist rule matching the SOline values. But the `_get_pricelist_rule` method still does all the price computation for 'nothing'. This commit skips the price computation (and the search of sub-rules if the rule found is based on another pricelist). --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Odoo now prevents users from manually creating payment tokens, which avoids confusing or unsafe records. Tokens are intended to be created only when linked to a customer's actual payment method details, improving payment data consistency.
Original PR description
Payment tokens should not be created manually, as it is useless, confusing and potentially harmful. They should only be created alongside payment details of a customer payment method. task-2848379 See also: - https://github.com/odoo/enterprise/pull/31199
Sales teams can now translate the default terms and conditions shown in sales settings. This helps companies present standard sales notes in the customer’s language, improving clarity for international customers.
Original PR description
Task: https://www.odoo.com/web?#id=1888280&action=333&active_id=131&model=project.task&view_type=form&menu_id=4720 Pad: https://pad.odoo.com/p/r.cb958720f0cc43d0beb7a71fdd2eb08a
Automatic next follow-up dates now adapt to the configured follow-up levels instead of using a fixed 14-day fallback. This makes customer payment reminders more consistent with each company's collection process and clarifies the behavior in the related tooltip.
Original PR description
Currently, when a next followup action date is set, it depends on the delay of the next followup level. If there is no next level, the date is arbitrarily set in 14 days. This is hard coded and doesn't depend on anything (aka it's weird and bad). This commit improves the setting of this next followup action date, by handling the different cases we can encounter: - by default (current behavior as well) -> next date set in (next level delay - current level delay) days - no next level -> next date set in (current level delay - previous level delay) days - no next level AND no previous level -> next date set in (current level delay) days - no level defined at all -> next date not set Also updates the tooltip to better explain this process. task id=3012793
The Master Production Schedule now includes filters to help users quickly find products that need replenishment, are under-replenished, or have excessive replenishment. The product column layout was also improved so checkboxes stay visible and better aligned with product names, making planning easier to review.
Original PR description
Support flilter by replenish state in mps
This change prevents users from manually creating payment tokens in subscriptions. Payment tokens will now only be created together with a customer's actual payment method details, reducing confusion and avoiding potentially harmful records.
Original PR description
Payment tokens should not be created manually, as it is useless, confusing and potentially harmful. They should only be created alongside payment details of a customer payment method. task-2848379 See also: - https://github.com/odoo/odoo/pull/99915