As mentioned in IRC, if an account has been disabled, it should appear within a <strike> tag wherever it's possible. The most obvious place for this is the assigned to as having a bug assigned to a disabled user could be a bad thing. It was also mentioned that users currently appear the suggested way within the "edit users" section. I will try to look into making a patch for this next week. It shouldn't be that difficult.

actually i was thinking about QA contact too.

The attacheted patch makes the following changes: * Create a sub in globals.pl called "DBID_to_mailto_link" * Change the "Reporter" and "Assigned To" fields in bug_form.pl to use this sub * Change the GetLongDescriptionAsHTML sub in globals.pl to use this new sub This will allow disabled accounts to appear struck in the afforementioned fields on the bug form as well as the addition comments area. Unfortunately, making the QA contact appear struck is beyond my abilities as it is in a text box and I have no idea how to handle that.

We could do a few things for QA Contact. a) Strike out "QA Contact" b) change from QA Contact: [QAAcount ] to QA Contact: -QAAcount- [QAAcount ] I think b is actually reasonable. an edit box for qa contact doesn't have to be that long. Thanks for doing this :-)

Do you think: a) QA Contact: -QAAcount- [QAAcount ] b) QA Contact: [QAAcount ] -QAAcount- is better? I'm thinking "b" for the sake of the text boxes all being aligned on the left... but I don't that it's really that major of an issue.

your b. a link to some url describing disabled accounts might be a good thing later.

IMHO the <strike> tag should be avoided wherever possible. For one, it is deprecated, see http://www.w3.org/TR/1999/REC-html401-19991224/present/graphics.html#h-15.2.1 But more important is that it makes the text very unreadable. See bug 40286 for an example. (I'm looking forward to the day when the fix for that bug is finally active at the mozilla.org installation!) IMHO the Right Way to do it is to change the foreground (and/or background) color, ideally with CSS.

-> New Bugzilla Product

Bug#96405 asks for mailto: links for the 'Assigned To' field, which this bug will provide. I agree that the 'disabled' style should be done using css (eventually, anyway). If this routine is used elsewhere, then it will also be possible to add in CSS support later for all places where a user is displayed throughout Bugzilla. It could also be used in the folowing places: show_activity 'who' column, buglist on owner/assigned_to/qa columns in the footer in the long description (maybe) Lastly, should the interface be changed (or a new (sub-)routine be used) in case a piece of code already has the (email/username/disabledtext) parameters, to avoid a DB lookup, if possible?

Owners/Assignees/QA Contact's names should not be a mailto:. This encourages people to mail rather than comment. We' had this discussion before :-) Does this patch actually do what the summary says? If it just did that, I'd review it. :-) Gerv

We are currently trying to wrap up Bugzilla 2.16. We are now close enough to release time that anything that wasn't already ranked at P1 isn't going to make the cut. Thus this is being retargetted at 2.18. If you strongly disagree with this retargetting, please comment, however, be aware that we only have about 2 weeks left to review and test anything at this point, and we intend to devote this time to the remaining bugs that were designated as release blockers.

Comment on attachment 21307 [details] [diff] [review] [PATCH] - See comments for more info This needs templates-related whacking. I agree that strike shouldn't be used because of the deprecation, but OTOH until CSS support really lands, there aren't that many good alternatives. As for readability (or lack thereof) I agree, but you don't generally have to read that many disabled account names anyway.

Interesting; I'd like to see how this would be done in buglist with out current template.

Bugzilla 2.20 feature set is now frozen as of 15 Sept 2004. Anything flagged enhancement that hasn't already landed is being pushed out. If this bug is otherwise ready to land, we'll handle it on a case-by-case basis, please set the blocking2.20 flag to '?' if you think it qualifies.

I looked at the first patch and didn't recognise the code at all :o Was Bugzilla really like that once?

Comment on attachment 717825 [details] [diff] [review] v2 patch The code is fine but the UI looks really weird. I think it's more confusing than helpful. If the assignee or reporter of a bug has a line through his name, what could this mean to the average user? Maybe italic would be better. The average user won't notice, and power users will know what this means.

(In reply to Frédéric Buclin from comment #16) > Comment on attachment 717825 [details] [diff] [review] > v2 patch > > The code is fine but the UI looks really weird. I think it's more confusing > than helpful. If the assignee or reporter of a bug has a line through his > name, what could this mean to the average user? Maybe italic would be > better. The average user won't notice, and power users will know what this > means. i don't see how italic would be clearer than a strike, given strike is used for everything else which is disabled on bugzilla. that said, i agree it looks messy/busy... how about updating $user->identity so it appends "(Disabled)" or some other admin-configurable text (including an empty string) ?

I was thinking maybe a params setting which has an HTML string which allows each installation to have their own value. For example, '<i>$user</i>' if you want italics or '$user (disabled)' if you want a string. Does that sound like a good idea? Default would be '$user' (i.e. do nothing)

I don't think a parameter is a good idea for such a thing. First of all, we try as hard as possible to limit the number of parameters in Bugzilla (and we did a pretty good job at killing many parameters since 2.20). Secondly, the display of disabled accounts would be different across Bugzilla installations, which would generate a lot of confusion among users (FAQ: how are disabled accounts displayed? - It depends!). Now the real question is: who cares about disabled accounts? The answer is: the average user who is simply reporting a bug and is not involved in the management of the project (i.e. most users) do not care about this information, first because they cannot do anything about it, and secondly because they wouldn't know what to do with this information. The only ones who should care are administrators and project managers. So for most users, the UI shouldn't render the disabled state too obviously to not confuse them, but the UI difference should still be noticeable for power users/admins/managers to realize that an account is disabled. That's why I suggested to use italics for disabled accounts. This way, if you don't pay attention to it, you simply don't notice it and you are not confused. The "(Account disabled)" text could be appended in the tooltip, though, not in the UI itself. Another reason why I think appending text in the UI itself is not a good idea is because 1) it broadens the field in bug reports, and 2) in buglists, only the first few letters are displayed in columns, and so you won't notice the extra text at all, unless you hover the field with your mouse.

(In reply to Frédéric Buclin from comment #19) > Now the real question is: who cares about disabled accounts? The answer is: > the average user who is simply reporting a bug and is not involved in the > management of the project (i.e. most users) do not care about this > information, first because they cannot do anything about it, and secondly > because they wouldn't know what to do with this information. The only ones > who should care are administrators and project managers. In FLOSS projects that have a mix of corporate (responsible for a specific code area) and volunteer users, volunteer users sometimes add corporate users to CC because they think that the corporate user is still around and responsible / interested in providing input on that bug report, while that corporate user has left the company in the meantime and hence is not involved in the FLOSS project anymore. And this slows down bugfixing sometimes. So in a kind of way users do care as it could at least *prevent* adding somebody to CC who will not even get notified about it anymore.

(In reply to Frédéric Buclin from comment #19) > users/admins/managers to realize that an account is disabled. That's why I > suggested to use italics for disabled accounts. This way, if you don't pay > attention to it, you simply don't notice it and you are not confused. The As Byron mentioned, having the text as italics would let to more confusion. Everything else in the Bugzilla UI uses strike through to indicate disabled or closed. > "(Account disabled)" text could be appended in the tooltip, though, not in > the UI itself. I am happy to do this by itself. Are you happy with that solution? Regards, Hugo

(In reply to Andre Klapper from comment #20) > volunteer users sometimes add corporate > users to CC because they think that the corporate user is still around This is another story, and it's actually bug 622679 which has been fixed 2.5 years ago. Disabled accounts are not suggested in the CC list when the auto-completion feature is enabled. (In reply to Hugo Seabrook from comment #21) > As Byron mentioned, having the text as italics would let to more confusion. > Everything else in the Bugzilla UI uses strike through to indicate disabled > or closed. Do not mix admin pages and user pages. The only place where disabled user accounts are marked as such is in editusers.cgi. In user pages, strike through is currently only used to indicate closed bugs.

The summary of the bug is "Disabled accounts should appear within a <strike> tag". LpSolit isn't happy with this. Marking as RESOLVED/WONTFIX. Hugo.

(In reply to Hugo Seabrook from comment #23) > LpSolit isn't happy with this. Marking as RESOLVED/WONTFIX. The bug summary can be reworded if necessary to better match what we want to do and other core developers besides glob didn't give their opinion yet. Let's keep the bug open for now.

Perhaps as an alternative to a tooltip, the user's display name could have " (Inactive)" appended? Whilst inactive accounts do not autocomplete - it's still easy to not realise the user is inactive - eg when filing a bug against an existing feature, and using hg annotate to find the original bug, and copying the user's email address directly from the assignee field of the original bug to the new one (eg as a needinfo).