Odoo Changelog — 2018-07-27

Friday, July 27, 2018

3 changes

Bug Fixes(3)

Resolved issues and error corrections

[FIX] web: empty input for empty password field

Coremasterweb

Odoo now correctly leaves password fields blank when no password value is set, instead of showing the word “false”. This avoids confusion for users editing records with empty password fields and keeps the form display accurate.

Original PR description

Revision on https://github.com/odoo/odoo/commit/4b3588feb2b7e260bf237b0f3944c90cdc47c3b5

In order to not replace characters with `'*'` in edit mode (because of `input`
with type 'password'), the above commit did not format the value at all.
The formatter of a char with the option 'isPassword' turns all of its
characters into `'*'`. That is not intended for password inputs, because the
content is hidden by the browser with the 'password' type.

The issue with not using the formatter is that an empty field has the value
`false`, so an empty password field produces an non-empty password input with
its value to 'false'.

This commit fixes the issue by forcing empty string for empty password values.

#password#forms#user interface

[FIX] stock: corssdock rules not update

PR #26009

CoremasterstockMEDIUM

This fix ensures cross-dock route rules are activated when a warehouse route already exists and is re-enabled. Businesses using warehouse cross-docking will avoid inactive rules that could prevent expected stock routing behavior.

Original PR description

It happens when the route is already set on the warehouse.
In this the system will only active the route however the rules
inside this route still inactive.

This commit set active the rules in both case when the route is created
or set as active.

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

#warehouse#cross-docking#routes

[FIX] web: edited password fields should not contain '*'

PR #25998

CoremasterwebMEDIUM

Fixes an issue where editing an existing password could accidentally save asterisks as part of the password. Users can now update password fields normally, helping avoid broken mail server or account settings after edits.

Original PR description

Before this commit, when someone was editing a password, the stored password may not be the expected one by the user. Step to reproduce: - open "Outgoing Mail Servers" form - set a password (e.g.…

Before this commit, when someone was editing a password, the stored
password may not be the expected one by the user.

Step to reproduce:

	- open "Outgoing Mail Servers" form
	- set a password (e.g. "yop")
	- save, then edit
	- add "y" at the end of the password field.

	> expected value: "yopy"
	> actual value: "***y"

In edit mode, the input is of type password, which visually hides the input
content even though the value is not ($input.val() displays the value).

The problem is due to the char field being rendered in edit mode using the
char formatter, which always hide the value of a password with '*':

	- This is not necessary in edit mode, because of the `<input>`
	  of type `'password'`.
 	- The field value is internally updated by using the `<input>`
 	  value, so it should store the correct password value.

This commit fixes the issue by making the formatter of password characters
being aware of the edit mode, so that passwords are not hidden in edit mode.

Task-ID 1869565

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

#password#forms#data integrity

Revision on https://github.com/odoo/odoo/commit/4b3588feb2b7e260bf237b0f3944c90cdc47c3b5 In order to not replace characters with `'*'` in edit mode (because of `input` with type 'password'), the above commit did not format the value at all. The formatter of a char with the option 'isPassword' turns all of its characters into `'*'`. That is not intended for password inputs, because the content is hidden by the browser with the 'password' type. The issue with not using the formatter is that an empty field has the value `false`, so an empty password field produces an non-empty password input with its value to 'false'. This commit fixes the issue by forcing empty string for empty password values.

It happens when the route is already set on the warehouse. In this the system will only active the route however the rules inside this route still inactive. This commit set active the rules in both case when the route is created or set as active. 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

Before this commit, when someone was editing a password, the stored password may not be the expected one by the user. Step to reproduce: - open "Outgoing Mail Servers" form - set a password (e.g. "yop") - save, then edit - add "y" at the end of the password field. > expected value: "yopy" > actual value: "***y" In edit mode, the input is of type password, which visually hides the input content even though the value is not ($input.val() displays the value). The problem is due to the char field being rendered in edit mode using the char formatter, which always hide the value of a password with '*': - This is not necessary in edit mode, because of the `<input>` of type `'password'`. - The field value is internally updated by using the `<input>` value, so it should store the correct password value. This commit fixes the issue by making the formatter of password characters being aware of the edit mode, so that passwords are not hidden in edit mode. Task-ID 1869565 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