Thursday, June 18, 2020
27 changes · master
Enhancements to existing features
Inventory workflows now default newly created products to storable items, allow product creation directly during inventory adjustments, and keep key transfer actions visible when records are unlocked. Replenishment is also easier to use with the stock app alone, reducing setup friction for businesses getting started with inventory management.
Original PR description
Adds improvements for inventory onboarding experience: 1. New Products "Storable" by default - Makes it so the default "Product Type" = "Storable Product" ('type'='product') when creating a new…
Adds improvements for inventory onboarding experience:
1. New Products "Storable" by default - Makes it so the default "Product Type" = "Storable Product" ('type'='product') when creating a new product in a manufacturing order, an inventory transfer, a Lot/SN, a scrap order, and a batch picking, . Previously the default was "Consumable".
2. Creating new products is possible in an inventory adjustment. This is possible in the following cases:
- Via the `product_ids` field in the `stock.inventory` form view
- Via the `product_id` field in the `stock.inventory.line` tree view **when** no `product_ids` assigned
These new products follow same "Storable" by default
3. Keep picking action buttons visible when unlocked. This covers buttons: "Check Availability",
"Validate", "Sign", "Print", "Return", "Unreserve", "Scrap", and "Cancel". Additionally relax the 'is_initial_demand_editable' restriction on 'qty_done' in 'stock_move_line_operation_tree' so that readonly status is only dependent on 'is_locked' status.
4. Make it so product replenishing can occur with just the stock module. This is done by adding a new "pull" rule in the receive routes. This rule is removed when installing manufacturing or purchase modules to prevent unexpected behavior for MTO related products. When manufacturing/purchase modules are removed, "pull" rule will not be re-added and it is expected that advanced users will be able to handle the case when customized receive route rules are deleted by installing manufacturing/purchase modules.
Task: 2220129
Enterprise PR: odoo/enterprise#10719
--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prOdoo now handles placeholders in translated messages more safely, reducing the chance that a bad translation breaks a workflow. Many existing messages were updated to the clearer format, improving translation quality and flexibility across languages.
Original PR description
Support two new syntaxes with `_()` method:
```py
_("This is so %s") % 2019
_("Text with %s placeholders", 42)
_("Text with %(num)s placeholders %(symbol)s", num=42, symbol="🧀")
```
The main benefit is to have a fallback on the source string if formating the
translated string fails (e.g. `"Foo %s"` translated `"Foo s%"`).
This PR converted most (but not all) calls to _ using placeholders to use the
new syntax. Hopefully, the remaining ones will be converted in the future and
avoid technical debt.
Use named placeholders when needed. If more than one placeholder is present in a
string, using named placeholder can be beneficial to reorder the placehodler
position (for languages like Japanese that do not use the same phrase
construction). On some sentences, it also brings clarity on the meaning of the
placeholders.
Task-id: 1853119This 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
Planning users can now start or open a chat by clicking an employee's avatar in the Gantt schedule. This makes it faster for managers and teams to contact the right person directly from the planning view.
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
Products created from the Barcode app during operations or inventory adjustments now default to Storable Product instead of Consumable. This better matches inventory workflows, helping ensure newly scanned or added products are tracked in stock correctly from the start.
Original PR description
This commit makes it so the default "Product Type" = "Storable
Product" ('type'='product') when creating a new product in the
barcode app's Operations or Inventory Adjustments. Previously the
default was "Consumable".
Specification 1 of Inventory Onboarding task.
Task: 2220129
Community PR: odoo/odoo#51676Resolved issues and error corrections
Hardware device processes are now stopped when a device is disconnected, instead of continuing to run in the background. This helps avoid unnecessary resource usage and potential connection issues when devices are unplugged or reconnected.
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. 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
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
This change fixes an error that could occur when editing a product's unit of measure. Odoo now keeps the sales and purchase units aligned before validation, helping users save product updates reliably.
Original PR description
This commit removes the onchange on product.product that sync uom_id with uom_po_id. It was problematic because of the constraint _check_uom on product.template. Updating the uom_id on a…
This commit removes the onchange on product.product that sync uom_id with uom_po_id. It was problematic because of the constraint _check_uom on product.template. Updating the uom_id on a product_product will eventually change also the uom_po_id to have them belonging to the same category. Saving the update call write() on product with a dict of two values (uom_id and uom_po_id) As product.product is inherited from product.template, the write() on the corresponding product_template is called but in this case 2 times for each values. The first time, only uom_id is updated. The _check_uom constraint is triggered and obviously failed. The uom_po_id on the template is not yet updated. To replace the onchange behavior, this commit make the sync in the beginning of write() of product.template. Which means before calling the constraint. Task : 2197818 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
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.
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