Password reset from admin page

I suggest to enable a totally different admin-only password reset here, where the admin would sent a new/interim password generated outside of AccountManagerPlugin, correct?

currently the admin logs in to trac and cganges the passwort of the user and sends the user the new password by mail from outlook. but this is not optimal because the admin has to do so many steps and he also knows the password afterwards. The password reset module (inside AccountManagerPlugin or outseide) should generate a interim password and send it to the user's mail address which is stored in the account properties.

Replying to bjoern.riemer@fokus.fraunhofer.de:

[...] The password reset module (inside AccountManagerPlugin or outseide) should generate a interim password and send it to the user's mail address which is stored in the account properties.

This clarifies things a lot.

Previously I thought, that you'd require password generation outside of the AccountManagerPlugin for some reason. So you can't use the standard login page, hence users have no reset option, but OTOH they can easily change their temporary password later, if logged in again.

Proposal for implementation: Add a second button "Reset passwords for selected accounts" below the user list and do the magic on all checked accounts with non-empty email. Would this be sufficient?

yes this would be the solution i'm looking for ;)

Ok, so let's do this improvement, as soon as some urgent security related stuff is done.

(In [10313]) AccountManagerPlugin: Prepare password reset code for use by admins, refs #7111.

This includes an important fix: Username and email must match or a valid temporary password for any existing account could be sent to an arbitrary unauthorized email address for capturing that account by a third person.

Now set_user_attribute() reveals it's potential for code cleanup as well.

(In [10315]) AccountManagerPlugin: Add support for admin-triggered password-reset, refs #7111.

After improving the underlying system this is the polish on-top of it.

Beware: To really enforce a password change we'd also need to invalidate the old password, since the 'lost password' procedure has been changed lately, so by default it doesn't overwrite any password prior to first successful login with the new (temporary random) password.

So you may call the current state a 'soft' reset. Do you need a 'hard' one at all? Please discuss.

BTW, administrative approval/blocking of user accounts is a different thing (see #843, #8595).

(In [10393]) AccountManagerPlugin: Releasing version 0.3, pushing development to 0.4.

This new feature release finally propagates a number of solutions into an official release, after some time of testing with trunk, so explicitely closes #442, #816, #2966, #3989, #4160, #6821, #7111, #8534, #8549, #8663, #8813, #8892, #8925, #8936 and #8939.

Should have made this months ago, but felt so many pending issues were too bad for a new release. But it has been a tremendous ticket burndown since last year, so it's really worth considering an upgrade now. See fresh changelog for details.

(In [10395]) AccountManagerPlugin: Releasing version 0.3, pushing development to 0.4.

This new feature release finally propagates a number of solutions into an official release, after some time of testing with trunk, so explicitely closes #442, #816, #2966, #3989, #4160, #6821, #7111, #8534, #8549, #8663, #8813, #8892, #8925, #8936 and #8939.

Should have made this months ago, but felt so many pending issues were too bad for a new release. But it has been a tremendous ticket burndown since last year, so it's really worth considering an upgrade now. See fresh changelog for details.

(In [12441]) AccountManagerPlugin: Propagate errors from AccountModule._reset_password, refs #7111, #8927, #10700 and #10701.

Thanks for the recent, anonymous hint on this issue, that originates from [10313] (btw, a fix for a much more serious issue).