Description

The verification status of an email address for an individual user can be seen by navigating to the Account Details page. However, on installations with many users, it would be nice to be able to see which accounts haven't been verified while viewing the Manage User Accounts page.

The initial idea I have for this is to the use the light grey color that is used for missing permissions (see ​t:#10752) on the Manage Permissions and Groups page. How does that sound? Any better ideas?

Change History (37)

In fact I'm already working on related improvements for the account table. But this is WiP and dedicated to adding some more tiny icons like for account locking. Suggestions welcome. A gray-out looks like a good one.

Thanks for the quick feedback. The patch in ​t:#10742 just applied the missing class to inactive permissions. This is the same class used for missing tickets, wiki pages, etc. So the first thought I had was to do the same for email addresses that haven't been validated and I'll work up a patch for this.

This looks like a good start, but because users with unverified account are treated similar to users in an anonymous session, I'll alter this into graying text of the whole row.

And the upcoming account approval/ban feature will use the same representation, probably with different tool-tip (title HTML tag). And different icon, that is what I've been working on before diving more into substantial enhancements with AcctMgr lately.

I guess that graying out the whole row is okay. I rather liked the idea of just having an explicit indicator on the email, but I'm not too wed to either approach.

Seen that and I like the idea too, but OTOH this might suggest an almost usable account, while quite the contrary is true: Until email is verify, there's hardly a difference to an unauthenticated session, given all elevated permissions are wiped for each request.

I've implemented the suggestion of graying out the entire row in th10741-r12501-1.patch​. The patch also implements #10743, and adds a title to the link for reviewing user attributes. Now that I've seen the change in action, I do prefer graying out the entire row rather than just the email address.

I'm thinking that eventually we should replace the link on the account name with a More details icon in the far right column.

Alternatively, we could drop the Review user account details page and show those details on the Manage user accounts page when expanding a More info section. Here is an example from a site that I use:

I'm partial to the latter idea at the moment, though it looks like it will only work when JavaScript is enabled, so we'd probably want to leave the Review user account details in place as a fallback when JavaScript is not enabled.

Now that I've seen the change in action, I do prefer graying out the entire row rather than just the email address.

I'm glad that we agree on this, but I've been unable to reproduce the gray-out be adding 'missing' class to 'tr' HTML tag. While I succeeded after adding a custom CSS rule, it still doesn't apply to the link labels, so could you investigate, where this CSS is coming from in your setup, please?

Yeah, I'll investigate. I'm not very proficient with CSS, so I wouldn't be surprised if the rule could be coded better. What version(s) of Trac did you test with?

I've been testing with Trac-1.0 by now, but I'm fine with a few extra CSS rules in acct_mgr.css, and it's actually working fine now. So don't dig for it too long - just make sure to test, if my final version is working for you as well.

I like the idea about moving the link to a dedicated column and label.

But the further it goes into implementation detail the more I get discouraged by the growing complexity. As witnessed with the email link issue (#10743) AcctMgr has already quite complex code structures, and I'd like to keep it at a reasonable level for now.

I don't say 'Never', but these changes won't happen in the near future. For now it works well, and the only thing that could force that change would be the introduction of some dedicated user page, like we have it at t-h.o, but this is not yet a generally agreed pattern.

Adding the registration approval configuration option to config admin panel.
Taking care for marking all potential message parts for translation as well.
A recent suggestion by Ryan J Ollos is merged in here too, so that all kinds
of restricted accounts are clearly visible in user listings now.

I've tested with Trac 1.1.1dev and everything is working well. I like that the configuration panel is starting to take shape now, with multiple options per fieldset. Before, it seemed overly boxed, but along with the change in [12506] in which two fieldsets were combined, it is starting to look nice, and logically organized.

I'll have to remember to take care in the future for translations. So far I have trained myself to remember to do this in Python code, but frequently tend to forget when working in the templates.

Although the more I look at this, I think maybe the system-message should be displayed in the location shown in comment:21. On first look, it just appears slightly out of place, particularly since add_notice is usually used to position similar messages at the top of the page.

I've tested with Trac 1.1.1dev and everything is working well. I like that the configuration panel is starting to take shape now, with multiple options per fieldset. Before, it seemed overly boxed, but along with the change in [12506] in which two fieldsets were combined, it is starting to look nice, and logically organized.

Ah well, you're welcome. It just occurred to me, that there was a more logical order, and binding related options would make it look even clearer, and I took the chance.

Although the more I look at this, I think maybe the system-message should be displayed in the location shown in comment:21. On first look, it just appears slightly out of place, particularly since add_notice is usually used to position similar messages at the top of the page.

I agree, that this is an odd place according to all standards. No wonder, I didn't take care for it. I would rather have it above the new Refresh/Reset, or even better: inside the section​, just to make clear what you did right now. Or the standard location on-top of the page, sure. But it looks a bit too far away.

In fact, I've been considering a patch to the Trac core for the plugin admin page that is patterned after your inline notices. After enabling or disabling a component, there is a notice at the top of the page, but it is usually out of site since the redirect contains a fragment that lands the user on the plugin for which the action was invoked.

In fact, I've been considering a patch to the Trac core for the plugin admin page that is patterned after your inline notices. After enabling or disabling a component, there is a notice at the top of the page, but it is usually out of site since the redirect contains a fragment that lands the user on the plugin for which the action was invoked.

I know what you mean. This has occurred to me many times before as well with similar uneasy feelings.

Add Comment

This ticket has been modified since you started editing. You should review the
other modifications which have been appended above,
and any conflicts shown in the preview below.
You can nevertheless proceed and submit your changes if you wish so.