Let user hide some fields.




19 years ago
7 years ago


(Reporter: CodeMachine, Unassigned)





19 years ago
A number of fields in the database are probably not universally applicable and
we should allow users to hide them  These are:

Assigned To
QA Contact
Target Milestone
Status Whiteboard
Anything in bug #24789 that gets implemented.
Attachment facilities.
Probably more ...

Notice how none of these are needed on the enter_bug screen.

So when do we hide them?  Firstly, on the show_bug screen.  Secondly, allow all
of these fields on the enter_bug screen, but allow them to be hidden.

Novice users should start with some of these fields off.  Basically the same
configuration we have now on enter_bug, possibly without CC.  Show_bug will then
be more simple for these users.

This will then allow you to make enter_bug more powerful for advanced users. 
Bugs #25521 and bug #5179 could come as a part of this!

Now how much would you expect to pay?  But wait, there's more!

Extend this to queries and you a simple query page for newbies (bug #16775), but
it is all still one query page, and people can define their own page somewhere
between easy and hard!

An implementation of this could really solve a lot of our problems.
This sounds like a good idea.  Now the question is how to implement it.  We would 
need some sort of way to store this in the user's preferences.  Ideally it would 
be expansible for the future.  How many fields are there now?  If there's 
significantly less than 64, we could use something similar to the groupsets that 
are used now (64-bit bitfield).  Also, how much should be visible to the user 
that hasn't logged in yet?  We have to remember also that not everyone has 
cookies turned on.  With the amount of personalization happening in Bugzilla now, 
it's almost impossible for anything to work correctly without being logged in 
yet.  Probably what should happen is a GoAheadAndLogIn tag be added to each of 
the pages that change based on what your user access is, and the Log In link at 
the bottom should always point to the page you're already viewing ("Log in and 
view this page again").  This is almost a subject for another bug, but it has an 
affect on how this idea would get implemented, so I'm mentioning it here.

Comment 2

19 years ago
Whoa, slow down.

I don't really like the idea of having bugs appear differently to different
people.  That will just lead to lots of confusion.  (Person A says "why does
this bug have the foo keyword on", and person B says "hey, I don't see that,
what are you talking about?")

As far as letting more advanced people do things on the query screen, that's not
a bad idea, and is already covered somewhat by bug 25521. 

Comment 3

19 years ago
It sounds to me almost like you are proposing an infinitely customizable query

screen, with tons of pieces you can add or subtract at will.  I'm not sure I

like this idea at all.  I don't like it because 1) It will mean TONS of new

preference settings to remember, and 2) If you REALLY want things to be simpler,

I say that also means keeping the number of complicated/confusing preferences

down.  It is NOT much help to simplify the query screen for immediate use if it

only means people will now have to select lots of new/confusing preferences on

the matter later.

For these reasons, I would rather see a simple query screen, which has only just

enough functionality to cover what (I think) about 90% of all newbies want to

enter for queries: namely keywords, be it in the summary field, or the

description field.  Someone correct me if I'm wrong, but it sounds to me like

the proposal made in the second attachment of bug 16775 should be able to cover

that 90% of newbies.  I favor using that as a basis for the simple query screen,

then having simply ONE preference, to allow the user to select whether he wants

to use that or the advanced query screen, where we can put things like the

boolean charts, the keyword, status whiteboard, assigned to fields, etc.

Comment 4

19 years ago
Um, this bug was proposing hiding things in the show_bug page, not in the query
Rereading the original description, it looks like it was proposing both...  After 
seeing the other comments here and thinking about it some more, I do agree that 
the number of preferences required for doing this would ultimately wind up more 
confusing to a newbie than the simplified form it would result in would.  I would 
perhaps opt for 2 or 3 predefined layouts with a preference to choose one of 
those, rather than having it "infinitely customizable" as proposed.

Comment 6

19 years ago
Yes, it applies to all pages.  You could have a different preference for each
page, but that would be going overboard.

It's not going overboard to have 20 (for example) different fields you can turn
on or off.  Not at all.  People seem to be confusing 20 similar preferences with
20 different preferences.

Adding 20 different preferences for 20 different features can be a preference
overload.  But these 20 preferences all _do the same thing_, add or remove a
field.  There is only one thing to understand here for a user.

Sure, they'd need to understand each field, but it's simple enough to explain
what each field does on the preference page, and simple enough for a user to
decide whether they want it.  This would pretty much be a once off thing.

You could have a set of field profiles, but I don't see that we're going to be
able to get a set that fits everyone.  Of course, a set of profiles plus a
custom profile option is always a choice.

Not logged on users should see the default set of information for a new user.

> I don't really like the idea of having bugs appear differently to
> different people.  That will just lead to lots of confusion.  (Person
> A says "why does this bug have the foo keyword on", and person B says
> "hey, I don't see that, what are you talking about?")

If you believe this is going to happen, the simple thing to do is explain it to
new users when they register.  This is a small price to pay in my opinion.  If
someone actually cared about the keywords they would likely have them on, and
that's the point of this bug.

So, yeah, this will happen, but it happens with every feature.  Will it happen
enough to warrant not implementing it?  I don't think so.  If this does start
happening regularly we can ask people why they didn't read the docs and go from

> As far as letting more advanced people do things on the query screen,
> that's not a bad idea, and is already covered somewhat by bug 25521.

I guess this could make the query screen more complex if the user desires, but
it's mainly about simplifying it.

Comment 7

19 years ago
Just a thought, if there was a wizard for setting preferences including this at
account creation time, that would let users know more about the features of
Bugzilla, including this.

Comment 8

19 years ago
No.  20 similar preferences are still 20 preferences.  Big preference screens
are a nightmare.  I'm not going there.

Also, 20 boolean preferences mean 2^20 = 1048576 different possible settings. 
QA people hate that kind of thing.

This whole thing is not likely to happen anyway, for reasons I've already
For a good example of what Terry just described, just look at edituser.cgi. :)  

The list of available access bit checkboxes is getting pretty big, and it already 

looks cumbersome. :)  And there's only 10 or so of those by default.  (I'll file 

another bug for an idea I have to clean that up a little)

Comment 10

19 years ago
Just wanted to say that although I do not agree with the solution Matthew Tuck

proposed here, I do think the original problem he aimed to solve is a very valid

one.  Correct me if I am mistaken anyone, but my impression is that everyone

here pretty much agrees with the original problem raised, namely that some

simplification of the simple query screen is necessary.

I still personally favor the idea of adopting a simple "90% of all simple

queries" query screen, and then having a single preference to allow the choice

of this or an advanced query screen, where we could put things like the "boolean

charts" feature (an *outstanding* innovation, which also originally came from

the mind of Matthew, I might add, and brought to life by Terry once he figured

out a way of implementing Matthew's idea).  Reason I am writing this is because

I just wanted to make clear that I am not meaning to shoot Matthew down flat out

here.  I do NOT want to do that at all...  I am only saying that I do NOT agree

with this *particular idea* of his.  It is an *interesting* idea, but I think

there are some very good reasons (which I have already stated) why this idea

would only make things worse.

Another possibility, maybe, would be to have 2 different layouts for the query

screen, the way the Mozilla Mail & News client currently has (2-pane or 3-pane

view).  This would be a compromise on Matthew's original idea.  However, I still

favor having a pref to choose between simple & advanced query screens.  The

reason I favor this is because I still think there is some functionality in the

query screen which "newbies" (as we were originally discussing) do not need, and

don't want, as it simply makes things confusing.  I say, let us "divide and

conquer" the two different camps of Bugzilla users, namely the newbies, who want

a simple query screen for their first queries, and an advanced screen, for those

who want to do more advanced stuff, and who aren't as easily put off by

complexity, and/or who have mastered the basics of Bugzilla.

I think we're starting to stray from the topic of this bug report, but I think 

zuperdee's got something here.  What if we created a "Most Common Searches" page, 

and add a button to the advanced query page for anyone with a certain superuser 

priv to "Add this query to the Canned Queries page"?

Comment 12

19 years ago
An interesting idea...  But there are 3 problems I see with that: 1) How many

"most common queries" will there be?  Bugzilla is a dynamic thing, and bugs

change all the time.  The bugs that are open/active now might not be active a

year from now.  If we simply let the "most common queries" build up infinitely,

we've got yet another problem on our hands: namely, lots of outdated queries

that simply keep building up.  2) Creating a "superuser," as you say, IMHO,

would only create a further division among Bugzilla users.  Since all Bugzilla

users are essentially in the same boat with regards to the fundamental purpose

(to report, document, and help diagnose/fix bugs), I think creating an

upper-class and lower-class bug reporter like this would simply tick off some

people.  I for one do NOT like the idea of creating a user that has further

privileges with Bugzilla that I do not have.  For Bugzilla to be of maximum

utility, EVERYBODY needs to have equal chance of using all of its features.

Granted, not everyone is as experienced with Bugzilla, but I think everyone

should have an equal OPPORTUNITY to use its features.  Creating a superuser like

this does not further that goal.  3) Further to #2, just what would the criteria

be for admitting "superusers?"  I think it a very dangerous idea to start

categorizing Bugzilla users according to how well they post bugs, for example.

This would open the door for censorship, which IMHO, is not in ANYONE's best


By 'superuser' I meant the person who maintains bugzilla, or someone he's 
designated to help out.  Hate to burst your bubble, but bugzilla already does 
this and has for quite some time.  Only people with the correct privs set can 
edit user accounts, and change the system preferences, etc.  This is what I 
meant.  The ability to add/remove things from the canned query page would be 
restricted to someone with one of those maintenance bits set.

Comment 14

19 years ago
That seems to me like it would create a lot of extra work for the maintainer of
Bugzilla, especially since as I say, common queries might change from
day-to-day.  IMHO, another problem with this idea is: how do you display such a
list?  I think it would be quite impractical to show each possible query if it
followed the form of the current query screen, for example.  For this reason, I
favor the idea of cleaning up the query screen first.
Well, for example, I have a couple canned queries on my site.  In this case, 

they're hard-coded in the index page, but a simple description of what is being 

searched is all that need be placed on the "canned queries" page.  You don't need 

a complete list of all the parameters.  For a good example, take a look at this 

page: <http://www.intrec.com/bugs> and look at the links on the right-hand side 

of the page.  I have no argument against cleaning up the query page however.

Comment 16

19 years ago
tara@tequilarista.org is the new owner of Bugzilla and Bonsai.  (For details,
see my posting in netscape.public.mozilla.webtools,
news://news.mozilla.org/38F5D90D.F40E8C1A%40geocast.com .)
Assignee: terry → tara


18 years ago
Whiteboard: Future-Target

Comment 17

18 years ago
moving to real milestones...
Target Milestone: --- → Future
-> Bugzilla product, trying User Interface component, reassigning.
Assignee: tara → myk
Component: Bugzilla → User Interface
Product: Webtools → Bugzilla
Version: other → unspecified

Comment 19

17 years ago
my .02 cents.

Getting back to the core of the summary which I think we can all agree on. The
pages both Show bug and Report a bug are both busier than they need to be for
the novices (end users outside of pure development/qa folks).

Here is my solution:

1. Take the current 2.17 query screen, move Status up to the top fold (above the

2. Put a button called "ADVANCED" that hides all the stuff below that fold.

3. Apply something very similar for the report bug screen.

4. Global or per-screen would be fine, everything else like multiple bug edit
and such just falls under advanced.

The simple truth is that too many form elements simply SCARE novice users. Give
then enough to get their feet wet, then they can just turn on advanced. I'll
leave mine on advanced.
The User Interface component now belongs to Gerv.  Reassigning all UNCONFIRMED
and NEW (but not ASSIGNED) bugs currently owned by Myk (the previous component
owner) to Gerv.
Assignee: myk → gerv
Reassigning back to Myk.  That stuff about Gerv taking over the User Interface
component turned out to be short-lived.  Please pardon our confusion, and I'm
very sorry about the spam.
Assignee: gerv → myk
Ok, so there are three pages in question (query, enter bug, show bug) and two
basic approaches (views by user type, user-specific field preferences).

Regarding views, we already have them (a.k.a. template formats), so the fix is
simple: just create additional user type-specific templates for each field, and
have a single preference for saying what type of user we are.  Unfortunately I
don't think we can come up with sets that satisfy enough people enough of the
time, and even one missing field can be a serious impediment to a user.

As for the latter, as Terry said tons of preferences are annoying, but we could
use DHTML to embed the UI into each page (f.e. via + or - toggles) so the user
never has to see a "preferences page" to configure their UI, they just delete
the fields they don't want to see and add back the ones about which they change
their minds.
Whiteboard: Future-Target
Target Milestone: Future → Bugzilla 2.22

Comment 23

14 years ago
*** Bug 301814 has been marked as a duplicate of this bug. ***

Comment 24

13 years ago
The trunk is now frozen to prepare Bugzilla 2.22. Only bug fixes are accepted, no enhancement bugs. As this bug has a pretty low activity (especially from the assignee), it's retargetted to ---. If you want to work on it and you think you can have it fixed for 2.24, please retarget it accordingly (to 2.24).
Target Milestone: Bugzilla 2.22 → ---


13 years ago
QA Contact: mattyt-bugzilla → default-qa


12 years ago
Assignee: myk → ui
You need to log in before you can comment on or make changes to this bug.