Anonymous | Login
Project:
RSS
  
News | My View | View Issues | Roadmap | Summary

View Issue DetailsJump to Notes ] Issue History ] Print ]
ID
0013510
TypeCategorySeverityReproducibilityDate SubmittedLast Update
feature request[Openbravo ERP] 01. General setupminorhave not tried2010-06-02 17:392022-02-01 08:08
ReporterplujanView Statuspublic 
Assigned ToTriage Platform Base 
PrioritynormalResolutionopenFixed in Version
StatusacknowledgedFix in branchFixed in SCM revisiond38c6dc4652c
ProjectionnoneETAnoneTarget Version
OSAnyDatabaseAnyJava version
OS VersionDatabase versionAnt version
Product VersionmainSCM revision 
Review Assigned To
Web browser
ModulesCore
Regression level
Regression date
Regression introduced in release
Regression introduced by commit
Triggers an Emergency PackNo
Summary

0013510: Inconsistent use of Password fields

DescriptionThere is a special field for passwords, with an special icon and an specific behavior. However, it is not used consistently.
As stated in rejected issue 0013491 setting the password for Initial Client Setup administrator user does not require the use of this password field. But when you create a new user by using the User window, that field type is used.
The password field is also used when setting request user password at Client window.
It is an inconsistent behavior and any end user will get confused about it.
Steps To ReproduceReview initial client setup, user and client windows.

Example flow:
1. Create a new client. At initial client setup window you are prompted to enter a username and password. Note that the password field is not the standard one. (See attach 1)
2. Logout
3. Login with the created user. You need a second admin user, so you go to User window. When entering the password for this one, the password field IS the standard one. (See attach 2) So behavior is inconsistent.
Proposed SolutionThere are two main ways of resolve this issue.

The best way is to replace the password fields (all of them) by the other ones.

The second way is to create a wiki page justifying this different behavior. Why it is valid to have a password field when creating the second administrator user and not for the first one.
TagsNo tags attached.
Attached Filespng file icon ICS_InitialClientSetupWindow.PNG [^] (17,855 bytes) 2010-06-02 17:39


png file icon ICS_UserWindow.PNG [^] (45,251 bytes) 2010-06-02 17:39


png file icon singlepw.png [^] (27,465 bytes) 2011-01-03 12:10

- Relationships Relation Graph ] Dependency Graph ]
related to defect 00134912.50MP19 closeddalsasua Password text field should appear as a popup window along with protected key symbol 
related to feature request 0000188 newjonalegriaesarte Initial Client Setup process should allow users to assign initial passwords for Admin and User users 
blocks feature request 0013494 closeddalsasua A confirm password must be added to the intial client setup window 

-  Notes
(0028053)
dalsasua (reporter)
2010-06-07 13:23

Hi all,

In issue 0013494 I'm requested to add a confirm password field in initial client setup. In this issue a general rule for password fields across whole erp is requested. I would like to clarify first this rule before changing anything.

This is the status:

Passwords are stored encrypted in database.
WAD generated windows solve this through a pop-up, where user enters the password, it is encrypted and saved encrypted in the correspondent field of the parent window.
In manual windows this is not necessary as the encryption can be done in the servlet.
The pop-up, from a UI perspective, is a pain. UIX has determined that suitable approach is to have two fields in the main window: password and confirm password. I can easily do this in initial client setup window, but would like to have an agreement before changing anything.

Thanks.
(0028182)
dalsasua (reporter)
2010-06-08 13:42

As agreed between platform, UIX and QA teams, initial client setup will provide two fields (with no pop-up) for password and confirm password, and wad-generated windows will provide the pop-up in order to encrypt password.
(0033511)
rgoris (developer)
2011-01-03 12:09

David, i just checked 2.50 MP25 on live builds and noticed that the user password in General Setup || Security || User || User does not have two password fields yet. Is this still planned to be done or was there a reason not to do it? See image
(0033558)
dalsasua (reporter)
2011-01-10 10:32

Asier: do you know something about a possible change in password fields in wad generated windows?

- Issue History
Date Modified Username Field Change
2010-06-02 17:39 plujan New Issue
2010-06-02 17:39 plujan Assigned To => adrianromero
2010-06-02 17:39 plujan File Added: ICS_InitialClientSetupWindow.PNG
2010-06-02 17:39 plujan File Added: ICS_UserWindow.PNG
2010-06-02 17:39 plujan Relationship added related to 0013491
2010-06-02 17:39 plujan Relationship added related to 0000188
2010-06-02 17:39 plujan Relationship added related to 0013494
2010-06-02 17:42 plujan version => main
2010-06-07 13:23 dalsasua Note Added: 0028053
2010-06-07 13:23 dalsasua Relationship deleted related to 0013494
2010-06-07 13:24 dalsasua Relationship added blocks 0013494
2010-06-08 13:41 dalsasua Status new => scheduled
2010-06-08 13:41 dalsasua Assigned To adrianromero => dalsasua
2010-06-08 13:41 dalsasua fix_in_branch => pi
2010-06-08 13:42 dalsasua Note Added: 0028182
2010-06-08 13:42 dalsasua Status scheduled => resolved
2010-06-08 13:42 dalsasua Fixed in Version => pi
2010-06-08 13:42 dalsasua Fixed in SCM revision => http://code.openbravo.com/erp/devel/pi/rev/d38c6dc4652cb8cf93dd89087644fa5831e20b47 [^]
2010-06-08 13:42 dalsasua Resolution open => fixed
2010-06-08 15:11 dalsasua Assigned To dalsasua => rgoris
2010-06-08 15:11 dalsasua Status resolved => new
2010-06-08 15:11 dalsasua Resolution fixed => open
2010-06-08 15:11 dalsasua Fixed in Version pi =>
2011-01-03 12:09 rgoris Note Added: 0033511
2011-01-03 12:10 rgoris File Added: singlepw.png
2011-01-03 12:11 rgoris Status new => acknowledged
2011-01-10 10:31 dalsasua Assigned To rgoris => alostale
2011-01-10 10:32 dalsasua Note Added: 0033558
2011-10-28 20:16 iciordia Type defect => feature request
2011-10-28 20:16 iciordia fix_in_branch pi =>
2017-04-10 14:38 alostale Assigned To alostale => platform
2022-02-01 08:08 alostale Assigned To platform => Triage Platform Base


Copyright © 2000 - 2009 MantisBT Group
Powered by Mantis Bugtracker