Open Bug 63524 Opened 24 years ago Updated 10 years ago

Make it possible to differentiate between active and disabled accounts (eg. with a tooltip)

Categories

(Bugzilla :: User Accounts, enhancement, P4)

2.11
enhancement

Tracking

()

People

(Reporter: jacob, Unassigned)

References

(Depends on 1 open bug)

Details

Attachments

(1 file, 1 obsolete file)

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 :-)
Keywords: patch, review
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.
Blocks: 67482
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.
No longer blocks: 67482
Blocks: 67482
No longer blocks: 67482
Target Milestone: --- → Bugzilla 2.16
Priority: -- → P4
-> New Bugzilla Product
Assignee: tara → myk
Component: Bugzilla → User Accounts
Product: Webtools → Bugzilla
Version: other → 2.11
Blocks: 96405
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?
No longer blocks: 96405
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.
Target Milestone: Bugzilla 2.16 → Bugzilla 2.18
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.
Attachment #21307 - Flags: review-
Severity: normal → enhancement
Depends on: 130276
Target Milestone: Bugzilla 2.18 → Bugzilla 2.20
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.
Target Milestone: Bugzilla 2.20 → Bugzilla 2.22
Assignee: myk → user-accounts
QA Contact: mattyt-bugzilla → default-qa
Target Milestone: Bugzilla 2.22 → ---
Attached patch v2 patchSplinter Review
I looked at the first patch and didn't recognise the code at all :o Was Bugzilla really like that once?
Assignee: user-accounts → hugo.seabrook
Attachment #21307 - Attachment is obsolete: true
Status: NEW → ASSIGNED
Attachment #717825 - Flags: review?
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.
Attachment #717825 - Flags: review? → review-
(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)
Flags: needinfo?(LpSolit)
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.
Flags: needinfo?(LpSolit)
(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.
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Resolution: --- → WONTFIX
(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.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
Assignee: hugo.seabrook → user-accounts
Status: REOPENED → NEW
Summary: Disabled accounts should appear within a <strike> tag → Make it possible to differentiate between active and disabled accounts (eg. with a tooltip)
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).
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: