Thursday, June 18, 2020
21 changes · master
Enhancements to existing features
This update aligns many Enterprise modules with Odoo’s newer translation wording format. It is an internal modernization that helps keep messages consistent and easier to maintain, with little direct impact on day-to-day users.
Original PR description
Enterprise part of odoo/odoo#52155
This update improves how budget records are queried behind the scenes, helping related budget information load more efficiently. It supports smoother performance for users working with accounting budgets without changing day-to-day workflows.
Original PR description
Enterprise part of odoo/odoo#42831
Resolved issues and error corrections
This fix ensures connected IoT payment devices stop their background activity when they are disconnected. It helps prevent lingering device processes that could affect reliability or resource usage after a disconnect.
Original PR description
The theads of devices were still running after 'disconnect' had been called. We add a '_run' variable that is set to True when the thread should be running.
Miscellaneous changes
Since the header effects are now done without duplicating the header into a fixed element, link anchors towards it were not working anymore as they could be redirected to the fixed-positioned header. This commit solves the problem "generically" for all fixed elements (I am not sure any link towards a fixed element except the header makes sense though). Forward-Port-Of: odoo/odoo#53134
Original PR description
Since the header effects are now done without duplicating the header into a fixed element, link anchors towards it were not working anymore as they could be redirected to the fixed-positioned header. This commit solves the problem "generically" for all fixed elements (I am not sure any link towards a fixed element except the header makes sense though). Forward-Port-Of: odoo/odoo#53134
Forward-Port-Of: odoo/odoo#53141 Forward-Port-Of: odoo/odoo#53120
Original PR description
Forward-Port-Of: odoo/odoo#53141 Forward-Port-Of: odoo/odoo#53120
- Create 2 companies A & B - Create a product with automatic valuation - Switch to company A - Create a SO for 1 unit of the product, validate and deliver - Genrerate the invoice - Switch to company B, but keep company A allowed - Post the invoice An error is raised because of inconsistent company: > Some records are incompatible with the company... This occurs because the anglo-saxon lines are created in accounts belonging to company B instead of company A. Since the product
Original PR description
- Create 2 companies A & B - Create a product with automatic valuation - Switch to company A - Create a SO for 1 unit of the product, validate and deliver - Genrerate the invoice - Switch to company B, but keep company A allowed - Post the invoice An error is raised because of inconsistent company: > Some records are incompatible with the company... This occurs because the anglo-saxon lines are created in accounts belonging to company B instead of company A. Since the product accounts are property fields, using `force_company` in the context allows the selection of the right accounts. opw-2276657 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#53166 Forward-Port-Of: odoo/odoo#53158
- Use an User with Accounting access rights, but without Admin access rights (e.g. Marc Demo) - Go to Accounting > Reporting > Tax Report An access rights error is triggered. opw-2275552 opw-2275115 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#53168
Original PR description
- Use an User with Accounting access rights, but without Admin access rights (e.g. Marc Demo) - Go to Accounting > Reporting > Tax Report An access rights error is triggered. opw-2275552 opw-2275115 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#53168
On a SO, you can set a default delivery address or a default invoicing address according to the customer. The same behavior has been applied on repair order. opw:2277679 Forward-Port-Of: odoo/odoo#53164 Forward-Port-Of: odoo/odoo#53117
Original PR description
On a SO, you can set a default delivery address or a default invoicing address according to the customer. The same behavior has been applied on repair order. opw:2277679 Forward-Port-Of: odoo/odoo#53164 Forward-Port-Of: odoo/odoo#53117
### Issue - Install Sales - Enable discounts & pricelists - Create a product - 2 variants: - first with "create variant" set to Always - second set to Never - Create a SO - Pricelist setting "without_discount" - Add the product with product configurator The line price is not correct (only Always taken in account) ### Cause When the variant has Create Variant set to Never we pass the extra money in the context. When we have a pricelist with "without_disco
Original PR description
### Issue - Install Sales - Enable discounts & pricelists - Create a product - 2 variants: - first with "create variant" set to Always - second set to Never - Create a SO - Pricelist setting "without_discount" - Add the product with product configurator The line price is not correct (only Always taken in account) ### Cause When the variant has Create Variant set to Never we pass the extra money in the context. When we have a pricelist with "without_discount" this context is not propagated correctly and it's lost ### Solution Propagate the context in order to have the extra money added to the price **OPW-2246102** -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#52427
Until version `13.0`, `ir.ui.view:postprocess_and_fields` returned a tuple of a string and a `dict` of field information. With aae1d578296875a641d1142c0f73279fc134a151, it now returns a `defaultdict` instead of the `dict`. This `dict` comes from `NameManager.available_fields`, which is initialized as a `defaultdict`. There is no apparent reason to have a `defaultdict` in this place, apart from the usage in `has_field`. Furthermore, using a `defaultdict` has a side-effect in the `search_vi
Original PR description
Until version `13.0`, `ir.ui.view:postprocess_and_fields` returned a tuple of a string and a `dict` of field information. With aae1d578296875a641d1142c0f73279fc134a151, it now returns a `defaultdict`…
Until version `13.0`, `ir.ui.view:postprocess_and_fields` returned a tuple of a string and a `dict` of field information.
With aae1d578296875a641d1142c0f73279fc134a151, it now returns a `defaultdict` instead of the `dict`.
This `dict` comes from `NameManager.available_fields`, which is initialized as a `defaultdict`. There is no apparent reason to have a `defaultdict` in this place, apart from the usage in `has_field`.
Furthermore, using a `defaultdict` has a side-effect in the `search_view` computed field of all the `ir.actions.act_window`. On a database, if you access `env.ref('base.paper_format_action').search_view` it will contain a stringified `dict`, and the string `default_dict(<class 'dict'>, {...})` is used in place of just `{...}` under the `fields` key:
```python
>>> print(env.ref('base.paper_format_action').search_view)
{
'model': 'report.paperformat',
'field_parent': False,
'arch': '<search string="Paper Format Config"><field name="name" modifiers="{"required": true}"/></search>',
'type': 'search',
'name': 'default',
'fields': defaultdict(<class 'dict'>, {
'name': {
'select': None,
'views': {},
'type': 'char',
'change_default': False,
'company_dependent': False,
'depends': (),
'manual': False,
'readonly': False,
'required': True,
'searchable': True,
'sortable': True,
'store': True,
'string': 'Name',
'translate': False,
'trim': True
}
})
}
```
Forward-Port-Of: odoo/odoo#52899Description 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#52850
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#52850
[FIX] account: make tax audit computation work with more complex CABA uses Before this, it was impossible to reconcile an invoice with a credit note, as the tax_audit field's computation found two invoice lines while it expected only one, and crashed. Note that our current tax report does still not handle all the cases properly: - Invoices with negative lines using cash basis taxes won't work well, as we can't differentiate a credit note from an invoice using only debit and credit. -
Original PR description
[FIX] account: make tax audit computation work with more complex CABA uses
Before this, it was impossible to reconcile an invoice with a credit note, as the tax_audit field's computation found two invoice lines while it expected only one, and crashed.
Note that our current tax report does still not handle all the cases properly:
- Invoices with negative lines using cash basis taxes won't work well, as we can't differentiate a credit note from an invoice using only debit and credit.
- Misc entries reconciled together with cash basis taxes on them ("faking" the invoice and payment) won't work well either, as both of them have the 'entry' type.
>> This commit is a temporary fix, essentially made to unlock customers blocked byt this issue. Another, more complete, fix is coming soon.
Forward-Port-Of: odoo/odoo#53062
Forward-Port-Of: odoo/odoo#53038The superuser is already used to check whether modules are installed with demo data and create the notification. It was not used for accessing the admin partner though, so in the case where a user is logging in with the password "admin" and with no access to `partner_admin` it's going to blow up the login process despite no reason to. @odony this could be fixed specifically as part of the TOTP PR (odoo/odoo#33928), but though it's difficult to achieve in "standard" odoo (requiring quite a
Original PR description
The superuser is already used to check whether modules are installed with demo data and create the notification. It was not used for accessing the admin partner though, so in the case where a user is logging in with the password "admin" and with no access to `partner_admin` it's going to blow up the login process despite no reason to. @odony this could be fixed specifically as part of the TOTP PR (odoo/odoo#33928), but though it's difficult to achieve in "standard" odoo (requiring quite a bit of messing up with the res.partner access rules) it still seems like an issue which is independent from TOTP, just more likesly to be hit with that enabled. Forward-Port-Of: odoo/odoo#53203
When using the options 'Hide countdown at the end', only the first canvas would dissapear and the message wasn't showing up. It was due to a return in a loop that would cause the code to stop at that point instead of just going to the next iteration as intented. task-2261649 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#52803
Original PR description
When using the options 'Hide countdown at the end', only the first canvas would dissapear and the message wasn't showing up. It was due to a return in a loop that would cause the code to stop at that point instead of just going to the next iteration as intented. task-2261649 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#52803
Prior to this commit the close button of the notification is wrongly placed when no title is provided. Applying this commit places the close button at the right end. This commit also modifies the size of the buttons to btn-sm. task-2277737 Fixes #52229 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#52982
Original PR description
Prior to this commit the close button of the notification is wrongly placed when no title is provided. Applying this commit places the close button at the right end. This commit also modifies the size of the buttons to btn-sm. task-2277737 Fixes #52229 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#52982
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#53103
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#53103
Forward-Port-Of: odoo/enterprise#11256
Original PR description
Forward-Port-Of: odoo/enterprise#11256
Before this commit, when a tracking value was changed and OCN was active, this change was send to notify also on Mobile when needed. But an issue was added in the message generator as the 'message.subtype_id.description' can be null. After this commit, we check that it's value is not null before processing it. Note: The Javascript/XML counterpart already check this possibility. Steps to reproduce: * Install OCN * User A must have no language set * Subtypes "discussion"/"note" have
Original PR description
Before this commit, when a tracking value was changed and OCN was active, this change was send to notify also on Mobile when needed. But an issue was added in the message generator as the 'message.subtype_id.description' can be null. After this commit, we check that it's value is not null before processing it. Note: The Javascript/XML counterpart already check this possibility. Steps to reproduce: * Install OCN * User A must have no language set * Subtypes "discussion"/"note" have no description nor translation of the description * Log in the mobile Android app with user B => he'll get an OCN token * User A pings user B in a chatter => crash opw-2279589 Forward-Port-Of: odoo/enterprise#11259
…or UserError Forward-Port-Of: odoo/enterprise#11098
Original PR description
…or UserError Forward-Port-Of: odoo/enterprise#11098
Fine tuning of https://github.com/odoo/enterprise/commit/8c00ab3aaf190e97258b224a8636de6089386d49 opw:2275320 Forward-Port-Of: odoo/enterprise#11248 Forward-Port-Of: odoo/enterprise#11203
Original PR description
Fine tuning of https://github.com/odoo/enterprise/commit/8c00ab3aaf190e97258b224a8636de6089386d49 opw:2275320 Forward-Port-Of: odoo/enterprise#11248 Forward-Port-Of: odoo/enterprise#11203
Steps to reproduce the bug: - Create a new alert under Subscriptions > Configuration > Alerts - Configure this alert to trigger on modification from stage 'Draft' to 'In Progress' - Select the action to add a tag and select an existing tag - Save the alert - Create a new subscription and save it - Move it to In Progress Bug: A traceback was raised: ValueError: Wrong value for sale.subscription.tag_ids: 1 opw:2274496 Forward-Port-Of: odoo/enterprise#1
Original PR description
Steps to reproduce the bug:
- Create a new alert under Subscriptions > Configuration > Alerts
- Configure this alert to trigger on modification from stage 'Draft' to 'In Progress'
- Select the action to add a tag and select an existing tag
- Save the alert
- Create a new subscription and save it
- Move it to In Progress
Bug:
A traceback was raised: ValueError: Wrong value for sale.subscription.tag_ids: 1
opw:2274496
Forward-Port-Of: odoo/enterprise#11247