308340 - General Preferences tab is empty except for submit button when no user prefences are enabled

Status: RESOLVED FIXED

(Bugzilla :: User Interface, defect)

Description

[Jon]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0

General Preferences tab is empty except for submit button when no user prefences
are enabled.  It looks strange to have a form with no fields.  Perhaps the tab
should not be displayed or a message displayed that there are no preferences
available.

Reproducible: Always

Steps to Reproduce:
1. Click on the User Prefences link
2. Disable all the preferences
3. Visit the General Preferences tab under the user's Prefs

Actual Results:  
saw screen with only a submit button

Comment 1

[Frédéric Buclin]

Makes sense to fix on the branch too, but this won't be trivial. The 'Submit
Changes' button is stored in template/en/default/account/prefs/prefs.html.tmpl
instead of settings.html.tmpl, making it a bit harder to handle.

In all cases, if there is no user pref enabled, a message should say "All user
preferences have been disabled". This will avoid invalid bug reports such as "I
cannot customize my prefs".

Comment 2

[Frédéric Buclin]

Attachment: patch, v1

applies on both the tip and 2.20

Comment 3

[Frédéric Buclin]

Note that this patch also removes the useless <form> from the permission page.

Comment 4

[Myk Melez [:myk] [@mykmelez]]

In addition to disabling the submit button and notifying users they can't change
any preferences, we should also display disabled form controls for each
preference.  Then users would be able to more easily discover what preferences
could be available so they can petition the administrator to enable them if it
makes sense.

Disabled form controls also mean the general preferences page won't change size
when preferences become enabled, and it's consistent with how we handle disabled
form controls elsewhere in Bugzilla (display them, so users know they exist, but
disable them, so users can't change them).

Comment 5

[Myk Melez [:myk] [@mykmelez]]

Another benefit is that disabled form controls shows users what the default
installations values are.

Comment 6

[Max Kanat-Alexander]

(In reply to comment #4)
> we should also display disabled form controls for each
> preference.

  I think that might tend to confuse and irritate users, because then there's a
bunch of form controls that they can't use, and they'll just email the admin
saying, "Hey, how do I activate these?"

  I think it should be entirely up to the admin whether or not the form controls
appear for the users, for that reason.

Comment 7

[Myk Melez [:myk] [@mykmelez]]

(In reply to comment #6)
> (In reply to comment #4)
> > we should also display disabled form controls for each
> > preference.
> 
>  I think that might tend to confuse and irritate users, because then there's
>  a bunch of form controls that they can't use, and they'll just email the 
> admin saying, "Hey, how do I activate these?"

It won't confuse users if we state that disabled preferences are those which can
only be changed by administrators for all users.  It might prompt some users to
request changes to the settings, but that's a benefit of this approach, since it
means admins will hear if the settings are inappropriate and will be able to
change them to better suit their user's needs.

Otherwise, users and admins have to resort to the much more cumbersome and
time-consuming process of users figuring out what they'd like to customize, not
seeing an option for doing so, and emailing admins about it, describing it
perhaps obliquely since they don't understand it perfectly; then admins
researching how to let users make those customizations and eventually
discovering (perhaps not until extensive research) that it's as simple as
enabling that preference they disabled last year and then forgot existed.

Comment 8

[Max Kanat-Alexander]

OK, that makes sense. The note on the General Preferences page that talks about
how only the admin can enable them should clear things up.

Comment 9

[Frédéric Buclin]

Attachment: patch, v2

As myk seems interested by this bug, let's ask him directly for review. The
patch applies cleanly on both the tip and 2.20.

Comment 10

[Frédéric Buclin]

Comment on attachment 196030 [details] [diff] [review]
patch, v2

looks like myk is busy

Comment 11

[Frédéric Buclin]

Attachment: patch, v2.1

fix a tiny bitrot

Comment 12

[GavinS]

Comment on attachment 200811 [details] [diff] [review]
patch, v2.1

1) Add has_settings_enabled to interface comment

NITS

a) Should we include the maintainer email address in the message?

b) use css for styling the new message?

c) Could add yourself to contributors maybe?

d) If the user has previously set a value, and the user setting is
   subsequently disabled by an admin, then I would prefer that value
   to be shown and not the system default, but that is a minor thing
   (and Myk seems to disagree in comment 5 anyway)

Comment 13

[Frédéric Buclin]

Attachment: patch, v3

For consistency with other templates, I don't filter the maintainer's email address, see bug 159631.

Comment 14

[Frédéric Buclin]

Bah.... the patch doesn't apply cleanly on the 2.20 branch due to the checkin of bug 302702. So I will either have to backport it or we retarget the bug to 2.22. I choose the second option for now. We can reopen and retarget it back to 2.20 if we really want it there too.

tip:

Checking in userprefs.cgi;
/cvsroot/mozilla/webtools/bugzilla/userprefs.cgi,v  <--  userprefs.cgi
new revision: 1.90; previous revision: 1.89
done
Checking in template/en/default/account/prefs/prefs.html.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/account/prefs/prefs.html.tmpl,v  <--  prefs.html.tmpl
new revision: 1.21; previous revision: 1.20
done
Checking in template/en/default/account/prefs/settings.html.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/account/prefs/settings.html.tmpl,v  <--  settings.html.tmpl
new revision: 1.3; previous revision: 1.2
done