Thursday, October 20, 2022
9 changes · master
Enhancements to existing features
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
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
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
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
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