Daily updates from Odoo
Tuesday, October 29, 2019
18 changes
New functionality added to Odoo
This change adds automated checks to build the documentation and catch formatting or compatibility issues earlier. It helps reduce recurring documentation build failures by testing against different tool versions and surfacing warnings before changes are merged.
Original PR description
The doc fails to build semi-regularly: * JS docstrings are incorrectly formatted or written in a way which breaks the parser * new versions of Sphinx remove APIs we're still using * doc fixes don't take older Sphinx versions in account This attempts to automatically build the doc using travis (for a multi-version text matrix, also because that's convenient). travis seems on the wane (apparently acquired & fired a bunch of folks). Apparent alternatives would be: * circleci, haven't managed to get it working yet & I don't understand how to get it working on non-master branch (other branches, PRs, …) (nb: [this might be useful](https://circleci.com/docs/2.0/oss/#build-pull-requests-from-forked-repositories)) * azure pipelines, haven't looked at it yet
Enhancements to existing features
Delivery carrier records can once again be archived from their form view. Archived carriers are also clearly marked with a visual ribbon, helping users avoid confusion when reviewing inactive delivery options.
Original PR description
Since the field active hase been removed from the form view of carrier we were not able to archive it from there anymore. So we've added back the 'active' field in invisible on the form view, and also added a ribbon on archived records. TASK-ID: 2115880 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
Resolved issues and error corrections
The invoicing guidance was adjusted so it no longer depends on accounting menus that may only be available in Enterprise installations. This helps users complete the invoicing walkthrough reliably, even when the full Accounting app is not installed.
Original PR description
The reason of these moves is that we reference some account accountant menu in the invoicing menu and if you are not in enterprise version with accounting installed, the tours don't work. The tours are adapted to this version. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an inconsistency in CRM stage lists where the probability field was shown even when it was hidden on the form view. Sales teams now see the same cleaner stage information across views, reducing confusion.
Original PR description
Description of the issue/feature this PR addresses: In the tree view probality is always show, but not in the view form. --> hide probality in the tree form too This PR apply the behavoir of the form view : https://github.com/odoo/odoo/blob/11.0/addons/crm/views/crm_stage_views.xml#L43 cc @tde-banana-odoo -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Creating a new Point of Sale configuration with the IoT Box option no longer incorrectly shows an unnecessary Save prompt caused by setup status being unavailable on new records. This makes the setup flow clearer while still ensuring the IoT module is installed when the configuration is saved.
Original PR description
When you create a new PoS config and you check 'IoT Box', you always saw the 'Save' button as if pos_iot was not installed yet. The save button is shown when `is_installed_pos_iot`, a computed field, is set to False. When creating a new record, this field is not computed yet so it is considered as False. We remove the `is_installed_pos` field and simplify the code. The PoS config view in `pos_enterprise` now overrides the one in `point_of_sale` and `pos_iot` overrides `pos_enterprise`. We still need to have the `module_pos_iot` field so that pos_iot will be installed when saving the PoS config. TaskID: 2090363
A problem from an incorrect forward-port in the UK reporting module was corrected. This helps keep the related user settings view consistent and avoids confusion or errors when managing UK reporting configuration.
Some guided test steps for invoicing were moved into the Accounting app where their related menus are available. This prevents those tours from failing when enterprise accounting is not installed, improving reliability for supported setups.
Original PR description
The reason of these moves is that we reference some account accountant menu in the invoicing menu and if you are not in enterprise version with accounting installed, the tours don't work. The tours are adapted to this version.
The Studio color picker has been updated to work correctly after recent changes to the website editor color picker. This keeps report and design customization in Studio usable and consistent with the latest editor behavior.
Original PR description
Some changes have benn done in the web_editor color picker. These broke the studio color picker, it is now fixed. Also an adaptation of the studio color picker to reflect these changes. Related to: odoo/odoo#39126 and: odoo/design-themes#181 task-2087383
Miscellaneous changes
The profiler was too optimistic. If the local variable `self` was not a cursor, it assumed it was automatically an Odoo model. Instead, only do the custom tracer methods when `self` is an instance of `BaseModel`. To reproduce the bug: 1. profile the `default_get` of `utm.mixin` ```python @profiler.profile() def default_get(self, fields): values = super(UtmMixin, self).default_get(fields) ``` 2. call this method in a shell ``` $ python odoo-bin shell -d 11c ...
Original PR description
The profiler was too optimistic. If the local variable `self` was not a cursor, it assumed it was automatically an Odoo model. Instead, only do the custom tracer methods when `self` is an instance of…
The profiler was too optimistic. If the local variable `self` was not a cursor, it assumed it was automatically an Odoo model.
Instead, only do the custom tracer methods when `self` is an instance of `BaseModel`.
To reproduce the bug:
1. profile the `default_get` of `utm.mixin`
```python
@profiler.profile()
def default_get(self, fields):
values = super(UtmMixin, self).default_get(fields)
```
2. call this method in a shell
```
$ python odoo-bin shell -d 11c
...
>>> self.env['utm.mixin'].default_get(['campaign_id'])
Traceback (most recent call last):
File "<console>", line 1, in <module>
File "</usr/lib/python3.7/site-packages/decorator.py:decorator-gen-67>", line 2, in default_get
File "/home/mat/odoo/odoo/odoo/tools/profiler.py", line 128, in _odooProfile
result = method(*args, **kwargs)
File "/home/mat/odoo/odoo/addons/utm/models/utm.py", line 73, in default_get
if request:
File "/usr/lib/python3.7/site-packages/werkzeug/local.py", line 327, in __bool__
def __bool__(self):
File "/home/mat/odoo/odoo/odoo/tools/profiler.py", line 41, in tracer
model = getattr(in_self, '_name', None)
File "/usr/lib/python3.7/site-packages/werkzeug/local.py", line 348, in __getattr__
return getattr(self._get_current_object(), name)
File "/usr/lib/python3.7/site-packages/werkzeug/local.py", line 307, in _get_current_object
return self.__local()
File "/usr/lib/python3.7/site-packages/werkzeug/local.py", line 137, in _lookup
raise RuntimeError("object unbound")
RuntimeError: object unbound
```
This error occurs because `self` is actually an object from `werkzeug` and we are using the custom `__getattr__` method which is not what was intended (the intention of the code was to check the content of the `_name` on the Odoo model).
Fixes odoo/odoo#30476
Forward-Port-Of: odoo/odoo#39355
Forward-Port-Of: odoo/odoo#39237get controller context at the very top: in ActionMixin 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#39475 Forward-Port-Of: odoo/odoo#39044
Original PR description
get controller context at the very top: in ActionMixin 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#39475 Forward-Port-Of: odoo/odoo#39044
Task : https://www.odoo.com/web#id=2082289&action=327&model=project.task&view_type=form&menu_id=4720 Pad : https://pad.odoo.com/p/r.1b9fe349cd290154300b6dc8c40c6ed8 after this commit : added a separator at the end of the inherited view task - 2082289 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-O
Original PR description
Task : https://www.odoo.com/web#id=2082289&action=327&model=project.task&view_type=form&menu_id=4720 Pad : https://pad.odoo.com/p/r.1b9fe349cd290154300b6dc8c40c6ed8 after this commit : added a separator at the end of the inherited view task - 2082289 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#38254
On the e-commerce app, you can add product variants. Those variants can have extra-image. Before this commit: - The variants extra image are displayed on every product of the same type and they are duplicated on the product variant. After this commit: - They are displayed only on the concerned product variant, without duplication. OPW-2088261 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is
Original PR description
On the e-commerce app, you can add product variants.
Those variants can have extra-image.
Before this commit:
- The variants extra image are displayed on every product of the
same type and they are duplicated on the product variant.
After this commit:
- They are displayed only on the concerned product variant,
without duplication.
OPW-2088261
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#39363Steps to reproduce the bug: - Let's consider product P with purchase_method = 'purchase' - Create a purchase order PO and puchase 20 units of P to a vendor - Confirm PO and create a vendor bill VB the 20 units of P - Validate VB - The invoiced quantity on PO is 20 - Go to the Purchase report and analyse the qty_to_be_billed Bug: The qty_to_be_billed was still equal to 20 instead of 0 opw:2091264 Forward-Port-Of: odoo/odoo#39442
Original PR description
Steps to reproduce the bug: - Let's consider product P with purchase_method = 'purchase' - Create a purchase order PO and puchase 20 units of P to a vendor - Confirm PO and create a vendor bill VB the 20 units of P - Validate VB - The invoiced quantity on PO is 20 - Go to the Purchase report and analyse the qty_to_be_billed Bug: The qty_to_be_billed was still equal to 20 instead of 0 opw:2091264 Forward-Port-Of: odoo/odoo#39442
- Create a POS user for which the corresponding partner has no email address. - Connect to the POS with the created user - Sell a product which creates a picking (e.g. Customizable Desk) The picking is created in draft and not validated. This is due to: https://github.com/odoo/odoo/blob/6435b27c35faeafca452d26fa7fd50a7fe964029/addons/mail/models/mail_thread.py#L2199 We disable tracking and post the message as `sudo()`. opw-2091808 Description of the issue/feature this PR a
Original PR description
- Create a POS user for which the corresponding partner has no email address. - Connect to the POS with the created user - Sell a product which creates a picking (e.g. Customizable Desk) The picking is created in draft and not validated. This is due to: https://github.com/odoo/odoo/blob/6435b27c35faeafca452d26fa7fd50a7fe964029/addons/mail/models/mail_thread.py#L2199 We disable tracking and post the message as `sudo()`. opw-2091808 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#39450 Forward-Port-Of: odoo/odoo#39423
- Create 2 products A & B in MTO, B with 'Buy' route + supplier - Create a BOM for A: 1 Unit of B - Create a MO for 1 Unit of A - In the PO created, change the quantity from 1 to 2, receive the products - In the MO, produce the unit and use 2 units of B The extra move of B is not valued. This is because the list of move to value is created before calling `super()`. Indeed, the extra move is created in `super()`, and moreover since this extra move is MTS (not MTO), the move line is
Original PR description
- Create 2 products A & B in MTO, B with 'Buy' route + supplier - Create a BOM for A: 1 Unit of B - Create a MO for 1 Unit of A - In the PO created, change the quantity from 1 to 2, receive the products - In the MO, produce the unit and use 2 units of B The extra move of B is not valued. This is because the list of move to value is created before calling `super()`. Indeed, the extra move is created in `super()`, and moreover since this extra move is MTS (not MTO), the move line is properly linked to the right move (unlike in #39121). We add the extra move to the list of moves to value. opw-2087592 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#39459
… instead of env.user.company_id to get the default country of a tax report line Forward-Port-Of: odoo/odoo#39457
Original PR description
… instead of env.user.company_id to get the default country of a tax report line Forward-Port-Of: odoo/odoo#39457
Apparently in the web client (and possibly expression.py, to check) an m2m is assimilated to a list of ids, thus `==` / `!=` should apply to the list of ids in the m2m. Before this, the comparison would be made to the SSF's raw m2m value, which is currently `[(6, _, ids)]`, therefore it would not be possible to test for an empty / non-empty m2m (or at least not in a way which worked in both the webclient and the SSF). Also add minor support for interpreting an o2m as an m2m, for multi-owne
Original PR description
Apparently in the web client (and possibly expression.py, to check) an m2m is assimilated to a list of ids, thus `==` / `!=` should apply to the list of ids in the m2m. Before this, the comparison would be made to the SSF's raw m2m value, which is currently `[(6, _, ids)]`, therefore it would not be possible to test for an empty / non-empty m2m (or at least not in a way which worked in both the webclient and the SSF). Also add minor support for interpreting an o2m as an m2m, for multi-owner o2m and other such oddities (cases where the o2m record does not *belong* to the "one" side). Forward-Port-Of: odoo/odoo#39433
In the next case: 1. Configure the next rates in USD: 25/10/2019 0.055556 24/10/2019 0.050000 2. Create a new customer invoice with date 24/10/2019 for 100 USD 3. Create a new payment for invoice in 2, with date 25/10/2019 for 1900 and mark the invoice as full paid. In this case, We adjust the rate in the CFDI, to allow stamp, this for the next validation in the PAC/SAT: The PAC ensure that the amount paid is less or equals that the sum of the amounts on each invoice, and whe
Original PR description
In the next case: 1. Configure the next rates in USD: 25/10/2019 0.055556 24/10/2019 0.050000 2. Create a new customer invoice with date 24/10/2019 for 100 USD 3. Create a new payment for invoice in…
In the next case: 1. Configure the next rates in USD: 25/10/2019 0.055556 24/10/2019 0.050000 2. Create a new customer invoice with date 24/10/2019 for 100 USD 3. Create a new payment for invoice in 2, with date 25/10/2019 for 1900 and mark the invoice as full paid. In this case, We adjust the rate in the CFDI, to allow stamp, this for the next validation in the PAC/SAT: The PAC ensure that the amount paid is less or equals that the sum of the amounts on each invoice, and when is multicurrency checks the amounts with the rate provided in the CFDI. Then, in this case: Monto="1900.00" TipoCambioDR="0.052632" If the invoice is full paid with this values, the CFDI could be signed: ImpPagado="100.00" This because 100 / 0.052632 = 1,899.9848. Note: The PR that adds the fix with the write-off only consider when the invoice and the payment are in the same currency, that are not affected here. https://github.com/odoo/enterprise/commit/390131f5ce018ab83a7292ed27aefdc86e5f365e Forward-Port-Of: odoo/enterprise#6457