After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 649814 - Cannot enable accounts without password
Cannot enable accounts without password
Status: RESOLVED DUPLICATE of bug 649816
Product: gnome-control-center
Classification: Core
Component: User Accounts
3.0.x
Other Linux
: Normal normal
: ---
Assigned To: Control-Center Maintainers
Control-Center Maintainers
Depends on:
Blocks:
 
 
Reported: 2011-05-09 16:58 UTC by Christoph Wickert
Modified: 2011-07-17 21:59 UTC
See Also:
GNOME target: ---
GNOME version: 2.91/3.0



Description Christoph Wickert 2011-05-09 16:58:13 UTC
Description of problem:
It is impossible to enable accounts without a password which renders the "Log
in without a password" option useless.

Version-Release number of selected component (if applicable):
control-center-3.0.1.1-4.fc15

How reproducible:
always

Steps to Reproduce:
1. 'System settings' -> 'User Accounts' -> Add user
2. Click on 'Account disabled'
3. 'Action' -> 'Log in without a password' or 'Enable this account' -> 'Change'

Actual results:
After the dialog closes, the 'Password' field will switch back to 'Account
disabled'.

Expected results:
Account should be enabled without password.
Comment 1 Philippe 2011-07-17 21:33:01 UTC
Hi Christoph.
Thanks for taking the time to report this bug.

I cannot reproduce the issue with the following version number: control-center-3.0.1.1.5.fc15.
It seems it has been corrected.

What I did:
- 'System settings' > 'User Accounds' -> 'Unlock'
- Use '+' to add an account
- Create a standard Account with a dummy name. 
- Click on 'Account disabled'
- Action: 'Log in without a password' -> 'Change'
- Result: the 'Password' field contains 'None' and that's ok.

I've also tested this with an administrator account and it behaves the same.

Moreover, it seems logical that 'Enable this account' has no effect at this stage, because we have never said til now if we want to set up a password or not.
What you can do:
- set up a password. It also enables the account.
- disable the account.
- enable the account again. There it works.

Here is what I'd suggest:
- close this bug (obviously RESOLVED in version 3.0.1.1.5),
- open an enhancement idea to not display the "Enable an account" option as long as no password has previously been set for this account.
What do you think of it?
Comment 2 Christoph Wickert 2011-07-17 21:57:52 UTC
Thanks Philippe,

your detailed instructions have helped me to understand my "fault". However what I did is logical because right after creation of an account the field "Password" reads "This account is disabled" (instead of "None" which is correctly displayed later), so I enabled the account.

IHMO this is a misconception of the UI. Disabling or enabling an account has *nothing* to do with the password. Even if you disable an account the password is still the same.

This being said the disable/enable option should not be in the password dialog but in the accounts dialog. It should be a slider below "Password" and above "Automatic login". Automatic login should then only be available if the account is really enabled. This would also fix bug 649816, so lets continue the discussion there.

*** This bug has been marked as a duplicate of bug 647441 ***
Comment 3 Christoph Wickert 2011-07-17 21:59:31 UTC
Oops, wrong duplicate. The correct one is 649816

*** This bug has been marked as a duplicate of bug 649816 ***