Allow admin to override verification status

[Tim Niemueller]

We are using Trac to host several git and svn repositories. For the latter we often have differing groups of authors and need to add them quickly using SvnAuthzAdminPlugin. If the EmailVerificationModule is turned on, there is no way to add a user with known-good credentials (e.g. professors) and send off the login data. The person must login to Trac first, add their personal data, and then confirm the Email address. Only afterwards the user will show up in the SvnAuthzAdminPlugin list of users.

What I'm suggesting is to add a box to the "Review User Account Details" page where I can confirm the user as an admin, so that afterwards the user can immediately be added using SvnAuthzAdminPlugin to a repository (path). Even more convenient, if at all possible, would be a check box on account creation with which I can confirm the entered user name and email address as legit. But I don't mind having to go through the account details page, it would still make my life much easier.

And in my dream scenario there would be a button "create random credentials and send by email"...

[Steffen Hoffmann]

Replying to TimN: ...

And in my dream scenario there would be a button "create random credentials and send by email"...

Believe it or not, but the button <Reset passwords> below current user list can do this already for all checked accounts, if email setup is working. I know, some work is still to be done regarding (email) notifications, but that's unrelated to this ticket.

[Steffen Hoffmann]

Replying to TimN: ...

The person must login to Trac first, add their personal data, and then confirm the Email address. Only afterwards the user will show up in the SvnAuthzAdminPlugin list of users.

What I'm suggesting is to add a box to the "Review User Account Details" page where I can confirm the user

...

How about an "authoritative" switch in the user properties editor, to instantly mark added accounts as confirmed? I know of 700+ Trac user applications, and they'd certainly rather stay in place than taking the detour to the user details each time. To me it would even be sensible to have this checked by default - it's an admin page after all. Thoughts?

[Steffen Hoffmann]

Replying to hasienda:

Replying to TimN: ...

And in my dream scenario there would be a button "create random credentials and send by email"...

Believe it or not, but the button <Reset passwords> below current user list can do this already

Hint: Use trunk development code to see all the latest feature additions. I'm working towards a next release, only it's not reached yet. Thanks for taking care.

[Steffen Hoffmann]

(In [11961]) AccountManagerPlugin: Admins add verified accounts by default, refs #843 and #10142.

If email verification is enabled, accounts created via the account property editor in AccountManagerAdminPanel are verified by default. Note, that the new user could still get an initial password assigned using the <Reset password> button on the same page.

A couple of small template improvements have been added, that I held off until now, because they'll need translators attention too. This is a good occasion.

[Steffen Hoffmann]

The implementation is made according to my last comments.

So your configuration will need to have basic settings for email notification and EmailVerificationModule enabled to even make the checkbox visible below the email input field in user properties editor of users admin panel. Then it works as expected: No email verification forced upon users, when changed by the admin with the "Skip new email verification" option checked - and that's the default. If you de-/re-select, this will be preserved over a series of POST requests. That's it - feedback welcomed.

[Steffen Hoffmann]

(In [11983]) AccountManagerPlugin: Some changes made with an eye on pylint check results, refs #843 and #10142.

Well, guess that especially [11961] has been a bit premature, and glad that I checked it that soon.

[Steffen Hoffmann]

(In [12398]) AccountManagerPlugin: Releasing version 0.4, pushing development to acct_mgr-0.5dev.

Availability of that code as stable release closes #874, #3459, #4677, #5295, #5691, #6616, #7577, #8076, #8685, #8770, #8791, #8990, #9052, #9079, #9090, #9139, #9246, #9252, #9547, #9618, #9676, #9843, #9852, #9940, #10023, #10028, #10123, #10142, #10204, #10276, #10397, #10412, #10594, #10625 and #10644.

Some more issues have been worked-on, yet without confirmed resolution, refs #5464 (for JiraToTracIntegration), #8927 and #10134.

And finally there are some issues and enhancement requests showing progress, but known to require more work to resolve them satisfactorily, refs #843, #1600, #5964, #8217, #8933.

Thanks to all contributors and followers, that enabled and encouraged a good portion of this development work.