[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

[Bug 1336] Impossible to edit user



http://bugs.skolelinux.org/show_bug.cgi?id=1336


holger@layer-acht.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |faj@bzz.no, holger@layer-
                   |                            |acht.org
             Status|RESOLVED                    |REOPENED
         Resolution|WONTFIX                     |




------- Comment #12 from holger@layer-acht.org  2009-03-07 17:52 -------
I'm unsure what to do here. 

To summarize what happened: 

lwat 0.16-1 had a bug, which allowed that admins can change user-passwords. It
was a bug, because the intended default behaviour was that admins couldnt do
that, but lwat automatically generates one, which is unchangeable to the admin.
In 0.16-1 the setting $allowPwSet in /etc/lwat/config.php was set to false.
0.16-1 was in our etch until February 19th 2009. 

lwat 0.17-1 silently (=without changelog entry) fixed that bug, so that it's
(in the default configuration) not possible anymore, to change the passwords.

http://bugs.skolelinux.org/1336 explains quite well, why teachers want to
change passwords and why changing the default behaviour in a stable release
update is bad.

So what should be done now? 

I suppose the best is to revert the bug fix and allow the admin to change the
password in any case, no matter what the config says.

This will "just" lead to problems, when the config is respected in lenny. (And
probably make upstream (hallo Finn-Arne :) somewhat unhappy.. :/

The proposed fix is to change line 1154 of lib/admin.php:
--                 pwgen(), ($allowPwSet ? "" : "readonly") ) ;
++                 pwgen(), ("true") ) ;


Comments?


-- 
Configure bugmail: http://bugs.skolelinux.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.


Reply to: