Changing an user's password can change another password for a different user

Should be fixed in svn now.

Confirmed. This is serious bug. Marking it critical wouldn't be a mistake.

Empty passwordedit when opening dialog before user data is synched.

I don't remember exactly, but I think that the same bug is present in Breezy, but I cannot verify.
Let you decide if needed to fix it.

bye

On Sunday 16 April 2006 13:46, <email address hidden> wrote:
> I don't remember exactly, but I think that the same bug is present in
> Breezy, but I cannot verify. Let you decide if needed to fix it.

I've fixed that one a couple of days ago, should be in the next release.

Cheers,
--
sebas

 http://www.kde.nl | http://vizZzion.org | GPG Key ID: 9119 0EF9
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Political language [...] is designed to make lies sound truthful and murder
respectable, and to give an appearance of solidity to pure wind. - George
Orwell, 1984

sorry, I've thought that was fixed only for dapper.

Thanx

I don't know if the fix will be backported (it's an obvious one-liner). I've fixed it in svn though, the fix should make it into the next release of guidance (and Kubuntu, FWIW).

I think the too fast fix keep a case for that bug.

Try this:
- create a new user
- put a password -> ok
- then with a console su new_user
- change the password as required
- go back in the user's password via gui
- do NOTHING just click ok
- go back to the console, su new_user again
- still OLD password has back

Previous case ^ only reproduced with 'new_user' as user name.

Try this third case:
- open an user
- change its password
- click ok
- click new user
- the password is the same typed for the user

reopen this bug, fixes is not so obvious one-liner :)

By design it does nothing if you have nothing in the password field.
            if self.passwordedit.password()!="":
                self.userobj.setPassword(self.passwordedit.password())
Can you confirm that the above case involves an empty password field, and that clicking OK simply does nothing?

Rocco if you try the exact things I've listed you can test these cases are buggy.
In the second case even with an empy field it changes back to the first password inserted.

Try them both ;)

The original description of the problem, where the second user appears to get the same password by default as the previously edited user, has been fixed (according to sebas) and I can't reproduce it here, so that fix appears to have been released. The new description, where you go to change the password and just click OK with a blank password field, works as designed - nothing happens. Possibly you should get an error dialog reminding you to enter something into the password field, but that would be a separate (nice, wishlist) bug. Can you still reproduce the original problem in kde 3.5.4? If not, please indicate that and/or mark the bug "fix released". If so, please indicate that as well.

ok probably I have to tell better:

- the original bug report is fixed, but I have found two more cases that aren't fixed, the two I've writed after, and for these I have reopened the bug
- kde 3.5.4 is installed, but the problem is in kde-guidance that isn't part of kde I think, anyway the two problems reported are STILL alive also with kde 3.5.4 and fully updated kubuntu 6.0.6.1
- the two cases that I have writed are bugs, if you cannot reproduce them is because probably you don't follow EXACTLY the steps as described

hope to have clarified

cimmo, you're reporting two cases, one of those is mistaken.

1) If you change the password of the user on the commandline with 'passwd' while you're editing the user with userconfig, you can expect that whatever you confirm last prevails. That is, if you use 'passwd' and then confirm via userconfig, the password you've set with passwd is lost.

2) The second case you're reporting (a new user's password is set to the one of the previous new user) is a bug indeed. I've committed a fix for that one to svn, it'll probably make it into Edgy. Don't know about Dapper (i.e. if it's grave enough to backport). Attached patch fixes it. Can you try the patch, and if it doesn't fix the second case you report, reopen the bug with an explanation how to reproduce it?

Thanks for keeping an eye on it though!

1) I didn't change the password with 'passwd', I only login for the first time the new_user and after the password the system asked me to change it, after changed it, you logout, go to edit via kde-guidance and just click ok and the previous password was restored.
I _never_ open at the same time kde-guidance and the user, I explain better:

- OPEN KDE-GUIDANCE
- create a new user called exactly as the default one: new_user
- put a password -> ok
- CLOSE KDE-GUIDANCE

- OPEN A CONSOLE
- su new_user
- change the password as ASKED
- logout
- CLOSE THE CONSOLE

- OPEN KDE-GUIDANCE
- open the new_user
- do NOTHING just click ok
- CLOSE the user and KDE-GUIDANCE

- OPEN the console
- su new_user
- still OLD password has back

Thanks for the clear explanation.

I've tried exactly what you did, and it worked as expected: The password I set when I was asked to has not been overwritten.

ok probably in svn something is changed, I cannot test kde-guidance that Riddell provides today in IRC because it cannot load the correct module in dapper, probably it is only for Edgy :(

I'm with Kubuntu Edgy and the second bug is still present, but I have seen that I have wrong the explaination steps, here the fixed ones that reproduce the bug.

- OPEN KDE-GUIDANCE
- create a new user called exactly as the default one: new_user
- put a password -> click ok
- DO NOT CLOSE KDE-GUIDANCE, leave it in the users list

- OPEN A CONSOLE
- su new_user
- change the password as asked
- logout

- open the new_user again in KDE-GUIDANCE
- do NOTHING just click ok

- go back in the console
- su new_user
- still OLD password has back