Daily updates from Odoo
Navigate
Branch
Friday, November 8, 2019
20 changes
Enhancements to existing features
This update tidies company-related setup in accounting and inventory. It helps ensure stock locations are created more consistently when a new company is added, while also simplifying related accounting company handling.
Original PR description
Split of https://github.com/odoo/odoo/pull/36804 for ~unrelated company cleanups -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This change makes common decimal number helper functions available directly from Odoo's Float field type. It simplifies development work by reducing extra imports, with no expected impact on end users or business processes.
Original PR description
**Description of the issue/feature this PR addresses:** In this PR it is possible to call the float utils by the Float class, exemple `fields.Float.is_zero(x)`. Like `fields.Datetime.to_string()`. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Resolved issues and error corrections
The update ensures IoT triggers can only be linked to the correct keyboard-type devices. This helps manufacturing users avoid setup mistakes and makes relevant triggers visible directly on the right device records.
Original PR description
- Add a domain on the device type when selecting an IoT device for an IoT trigger. - Show IoT Triggers in the form view of devices if they have type 'keyboard' instead of 'device'
Features or functions removed from Odoo
Old unused code was removed from the financial reporting area to simplify ongoing maintenance. This cleanup should not change day-to-day behavior, but it helps reduce complexity and future maintenance risk.
Original PR description
Split of https://github.com/odoo/enterprise/pull/5564 for ~unrelated company cleanups Co-Authored-By: Laurent Smet <las@openerp.com>
Miscellaneous changes
-- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#40034
Original PR description
-- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#40034
Until now keyboard devices are only supported if their bInterfaceProtocl = 1 However for one of the scanner advise in the module "Inventory" this interface = 0 We therefore adapt the code so that if the interface is at 0 it is recognized as a scanner. Task ID: 2121725 Forward-Port-Of: odoo/odoo#40028
Original PR description
Until now keyboard devices are only supported if their bInterfaceProtocl = 1 However for one of the scanner advise in the module "Inventory" this interface = 0 We therefore adapt the code so that if the interface is at 0 it is recognized as a scanner. Task ID: 2121725 Forward-Port-Of: odoo/odoo#40028
Prerequisites - Configure a mail server (incoming) - Enable leads in CRM app - Create a sales team with a mail alias (ex: testcrm@odoo.com) and check "Pipeline" and "Leads" - Set a partner email with one of yours (ex: bob@odoo.com) /!\ - Send a mail from bob to testcrm - In the incoming mail server click on "Fetch" Reproduce the issue: - Convert the generated lead to an opportunity - Choose "Existing customer" and set another one than the act
Original PR description
Prerequisites - Configure a mail server (incoming) - Enable leads in CRM app - Create a sales team with a mail alias (ex: testcrm@odoo.com) and check "Pipeline" and "Leads" - Set a partner email with…
Prerequisites
- Configure a mail server (incoming)
- Enable leads in CRM app
- Create a sales team with a mail alias (ex: testcrm@odoo.com)
and check "Pipeline" and "Leads"
- Set a partner email with one of yours (ex: bob@odoo.com) /!\
- Send a mail from bob to testcrm
- In the incoming mail server click on "Fetch"
Reproduce the issue:
- Convert the generated lead to an opportunity
- Choose "Existing customer" and set another one than the actual
- The opportunity is created but the customer is the old one
Cause:
The given partner_id is overriden by the old one in the
`handle_partner_assignation` method.
This commit gives the priority to the new partner_id.
OPW-2089404
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#40001When the forward-port-bot detects a conflict, a commit with the conflicting files is created. It could happen that the file is not covered by the test, leaving the runbot green. In that case, if the PR is rplused by accident, the file is merged as is with then conflict marker. This PR adds a new test that search for the conflict markers. Forward-Port-Of: odoo/odoo#39994 Forward-Port-Of: odoo/odoo#39813
Original PR description
When the forward-port-bot detects a conflict, a commit with the conflicting files is created. It could happen that the file is not covered by the test, leaving the runbot green. In that case, if the PR is rplused by accident, the file is merged as is with then conflict marker. This PR adds a new test that search for the conflict markers. Forward-Port-Of: odoo/odoo#39994 Forward-Port-Of: odoo/odoo#39813
Firstly bd49f9fd17a did some fixes that removed a bunch of code containing '`install_mode_data`'. Later, 627292f7f31 replaced '`install_mode_data`' for '`install_filename`'. Finally, 43dd9ecd827 reverted bd49f9fd17a (including '`install_mode_data`' remnant). **Description of the issue/feature this PR addresses:** This PR fixes 43dd9ecd827 to make it compatible with 627292f7f31. **Current behavior before PR:** (that's how I detected it): - install `project` - call odoo with `--dev=a
Original PR description
Firstly bd49f9fd17a did some fixes that removed a bunch of code containing '`install_mode_data`'. Later, 627292f7f31 replaced '`install_mode_data`' for '`install_filename`'. Finally, 43dd9ecd827 reverted bd49f9fd17a (including '`install_mode_data`' remnant).
**Description of the issue/feature this PR addresses:**
This PR fixes 43dd9ecd827 to make it compatible with 627292f7f31.
**Current behavior before PR:**
(that's how I detected it):
- install `project`
- call odoo with `--dev=all` (not sure if this affects in this case).
- upgrade `project` module.
- it shows `WARNING [DB] odoo.addons.base.models.ir_ui_view: Could not find view arch definition in file '.../odoo/addons/project/security/project_security.xml' for xmlid '('base.user_groups_view', 'user_groups_view')' `
**Desired behavior after PR is merged:**
The thing gets fixed.
--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#39992The third parameter to assertAlmostEqual is a precision (places), not the assertion message. This goes unnoticed when using two objects which are strictly equal because assertAlmostEqual shortcuts if the two inputs are equal, before falling back on approximation. Since the parameters here are two integers, they're always going to be either identical or completely different, therefore the issue is only visible if the assertion fails, hiding the assertion error. * pass the message by
Original PR description
The third parameter to assertAlmostEqual is a precision (places), not the assertion message. This goes unnoticed when using two objects which are strictly equal because assertAlmostEqual shortcuts if the two inputs are equal, before falling back on approximation. Since the parameters here are two integers, they're always going to be either identical or completely different, therefore the issue is only visible if the assertion fails, hiding the assertion error. * pass the message by keyword * replace assertAlmostEqual by assertEqual as the inputs are integers and integers can't really be "almost" equal 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#40015
Updates to the customer display were sent too often: - Twice when creating a new order - Twice when removing a payment line - Every time the status of a payment line with a terminal changed -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#39179
Original PR description
Updates to the customer display were sent too often: - Twice when creating a new order - Twice when removing a payment line - Every time the status of a payment line with a terminal changed -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#39179
When the user changed the parallax option, it was only updated on save. So, the user was not able to have a preview of what he chose. Note: this commit is made in saas-12.3 but does not fully solve the problem there... and unfortunately I don't know why. It fully solves the problem in 13.0 though and this is more important. Forward-Port-Of: odoo/odoo#39971
Original PR description
When the user changed the parallax option, it was only updated on save. So, the user was not able to have a preview of what he chose. Note: this commit is made in saas-12.3 but does not fully solve the problem there... and unfortunately I don't know why. It fully solves the problem in 13.0 though and this is more important. Forward-Port-Of: odoo/odoo#39971
Forward-Port-Of: odoo/odoo#39978
Original PR description
Forward-Port-Of: odoo/odoo#39978
Pad:https://pad.odoo.com/p/r.c19875b95b59d4c5ed6e194028b99f96 Task:https://www.odoo.com/web#id=2059779&action=333&active_id=967&model=project.task&view_type=form&menu_id=4720 Forward-Port-Of: odoo/odoo#36119
Original PR description
Pad:https://pad.odoo.com/p/r.c19875b95b59d4c5ed6e194028b99f96 Task:https://www.odoo.com/web#id=2059779&action=333&active_id=967&model=project.task&view_type=form&menu_id=4720 Forward-Port-Of: odoo/odoo#36119
- Create 2 companies A & B - Create a website A - Create a user U with access to company B only - Connect as U and go to the website An internal server error is raised. This is due to 7bfcb53db37f385a99 which verifies if the user isn't granted access to companies he is not supposed to access. This is exactly what was done before this commit: the website is in a company not allowed to the user. To avoid this, we simply keep the companies of the user in the context. opw-2116539
Original PR description
- Create 2 companies A & B - Create a website A - Create a user U with access to company B only - Connect as U and go to the website An internal server error is raised. This is due to 7bfcb53db37f385a99 which verifies if the user isn't granted access to companies he is not supposed to access. This is exactly what was done before this commit: the website is in a company not allowed to the user. To avoid this, we simply keep the companies of the user in the context. opw-2116539 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#39921
fixes #39698 Forward-Port-Of: odoo/odoo#39700
Original PR description
fixes #39698 Forward-Port-Of: odoo/odoo#39700
Usecase to reproduce: - Create a purchase requistion with type Call For Tender - Update a line and set the price to zero. UserError 'You cannot confirm the blanket order without price.' raised. It happens because the write don't process the same check than create and don't check if the purchase_requistion is a blanket order or a call for tender. It also doens't check the current state of the purchase_requisition. Task: 2120211 Forward-Port-Of: odoo/odoo#39883
Original PR description
Usecase to reproduce: - Create a purchase requistion with type Call For Tender - Update a line and set the price to zero. UserError 'You cannot confirm the blanket order without price.' raised. It happens because the write don't process the same check than create and don't check if the purchase_requistion is a blanket order or a call for tender. It also doens't check the current state of the purchase_requisition. Task: 2120211 Forward-Port-Of: odoo/odoo#39883
In editable list view, moving to next cell using TAB key crash when the following field is read-only (i.e non-focusable) and an onchange() event is triggered. Consider an editable tree view like this: ```xml <form> <field name="o2m" onchange="1"> <tree> <field name="description"/> <field name="date" readonly="1"/> <field name="type"/> </tree> </field> </form> ``` 1. Adding a new line will give focus to `description` field widget
Original PR description
In editable list view, moving to next cell using TAB key crash when the following field is read-only (i.e non-focusable) and an onchange() event is triggered. Consider an editable tree view like…
In editable list view, moving to next cell using TAB key crash when the
following field is read-only (i.e non-focusable) and an onchange() event
is triggered.
Consider an editable tree view like this:
```xml
<form>
<field name="o2m" onchange="1">
<tree>
<field name="description"/>
<field name="date" readonly="1"/>
<field name="type"/>
</tree>
</field>
</form>
```
1. Adding a new line will give focus to `description` field widget
(currentFieldIndex is 0)
2. issuing a TAB keypress, will call _onNavigationMove which calls
_selectCell() with fieldIndex of 1
3. The _selectCell() method set widget currentFieldIndex to the new value
(currentFieldIndex is 1) add call _activateFieldWidget() to activate
on the corresponding widget.
4. _activateFieldWidget() will fail to activate the `date` field as it's
readonly, then try for next ones and succeed to activate the `type` field
cell
5. When focus is given a `type`, the `description` field is blurred which
trigger an onchange() and the controller apply those changes to the
editable list rendererd using the confirmUpdate() method.
The confirmUpdate() will try to get the current selection, but that
field is actually set to the `date` field (currentFieldIndex = 1),
which is readonly and so has no focusedElement - triggering the crash.
This commit ensure we don't try to call getSelectionRange() it current widget
has no focusable element.
OPW-2075229
--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#39942
Forward-Port-Of: odoo/odoo#39811To give the possibility to the user to cancel transactions, we used to execute them in asynchronous mode. This allowed us to listen for abort actions coming from the PoS. We switched to asynchronous mode before starting the transaction and back to synchronous right after. We query the status of the terminal 20 seconds. If the check happened while the async mode was activated, the call to the API indefinitely blocked and all the following transactions had to wait. To continue using his t
Original PR description
To give the possibility to the user to cancel transactions, we used to execute them in asynchronous mode. This allowed us to listen for abort actions coming from the PoS. We switched to asynchronous mode before starting the transaction and back to synchronous right after. We query the status of the terminal 20 seconds. If the check happened while the async mode was activated, the call to the API indefinitely blocked and all the following transactions had to wait. To continue using his terminal, the user had to reboot his box. We don't need to execute transactions asynchronously anymore. We listen for abort actions in the main thread while transactions are processed in another one. Forward-Port-Of: odoo/enterprise#6430
The "Send Balance" button in the PoS was always showing and we always tried to perform a Balance operation before closing the PoS, even with Ingenico payment terminals, resulting in errors. We now only perform that operation with Six payment terminals. Forward-Port-Of: odoo/enterprise#6341
Original PR description
The "Send Balance" button in the PoS was always showing and we always tried to perform a Balance operation before closing the PoS, even with Ingenico payment terminals, resulting in errors. We now only perform that operation with Six payment terminals. Forward-Port-Of: odoo/enterprise#6341