46296 - Make editparams.cgi be multi-panel by category

Status: RESOLVED FIXED

(Bugzilla :: Administration, task, P4)

Description

[Dave Miller [:justdave]]

I keep seeing mention in bug reports here and there about doing this, but I can't 
find one specifically for doing this, so I'm creating one.

The params need to be moved out of a flat-file into the database, so that the 
parameter definition is easily expansible (such as adding a category column for 
each parameter - see below).

Also, editparams.cgi needs to be changed to use the above suggested param format 
in order to sort parameters by category, probably in a multi-panel format, 
similar to the way the user preferences are currently handled.

Comment 1

[Chris Yeh]

something to keep in mind for the schema change. reassigning to me

Comment 2

[Jacob Steenhagen]

Chris, are when you say "the schema change", are you refering to 3.0?  Or
will/should it be done sooner than that?

Comment 3

[Dave Miller [:justdave]]

Moving to real milestones...

Comment 4

[Hixie (not reading bugmail)]

Taking all Bugzilla 3.0 bugs -- congratulations to MattyT for the triage, it
really was spot on. Note: I may end up pushing some of these bugs back to 3.2,
we'll see. However, I believe all these bugs should just fall out of the 
redesign. Let's hope I'm right!

(Note: I'm also resetting the priority field to "---" so that I can retriage any
that I consider important or likely to be dropped.)

Comment 5

[Dave Miller [:justdave]]

*** Bug 84293 has been marked as a duplicate of this bug. ***

Comment 6

[Dave Miller [:justdave]]

anyone writing a patch for this please see the comments on bug 84293.

Moving this to 2.16.  We can't wait for 3.0 on this, the params page is becoming 
way too unweildy way too quickly.

Comment 7

[Matthew Tuck [:CodeMachine]]

Moving to new Bugzilla product ...

Comment 8

[GavinS]

Once all the params are in the DB, would they still be cached somewhere in a file?

I was looking at the 'bugzilla is unavailable because of a backup' page a while
ago, and I wondered how the 'headerhtml' param, for instance, would be retrieved
if the DB was unavailable?

Comment 9

[GavinS]

Is anyone else looking at this? If so, I'll pick another bug to have a look at...

If not, then as I've had a bit of a look at this, I've got a few questions and a
db proposal, if anyone has any ideas or suggestions...

1) (as per my previous comment) How should parameters like 'shutdownhtml' be
managed? If the DB is down, then we can't look it up, and wouldn't want to try.

2) I like the idea of only reading (and caching) parameters when they are
needed. In people's experience, would that actually make much of a startup
difference compared to reading in all the parameters early on for every Bugzilla
page?

3) There is a bit of a problem when it comes to reading the Params from the DB:
if the SendSQL() routine needs any params (which it does), then it will need to
look them up, which will, of course require SendSQL()... :( 

I'm contemplating number 3) at the moment.


Anyway, here is a proposed DB to support the global parameters, which,
fortunately, should also support the user params in bug#98123...

Index: checksetup.pl
===================================================================
RCS file: /opt/repositories/sysadmin/src/bugzilla/checksetup.pl,v
retrieving revision 1.1.1.4
diff -w -u -r1.1.1.4 checksetup.pl
--- checksetup.pl	2001/08/30 09:01:06	1.1.1.4
+++ checksetup.pl	2001/09/14 15:17:18
@@ -1127,6 +1127,120 @@
      index(userid)';
 
 
+#
+# Preferences Group table
+#
+# pref_group_name - e.g. 'mail', 'admin', 'ldap', 
+#
+# pref_group_display_name - Used for GUIs
+#
+# pref_group_desc - Description of the group
+#
+# pref_group_sort_order - Used to order the display of preference groups,
+#                         however they are displayed
+#
+$table{'pref_group'} = 
+    'pref_group_id mediumint not null auto_increment primary key ,
+     pref_group_name varchar(50) not null ,
+     pref_group_display_name varchar(50) not null ,
+     pref_group_desc varchar(255) not null ,
+     pref_group_sort_order smallint not null ,
+
+     index(pref_group_name),
+     index(pref_group_sort_order)
+
+    ';
+
+# Preference definitions
+#
+# pref_defs_id - Unique Id for this preference definition (is auto_increment a
+#                MYSQL-specific concept?)
+#
+# pref_group_id - ID of a row in the pref_group table
+#
+# pref_display_order - Used to order the display of prefs on GUIs, within a 
+#                      particular pref. group 
+#
+# pref_display_name - string to display on GUIs
+#
+# pref_name - string used to id this pref in code. List of valid pref/
+#             names will be stored in globals.pl, or something like a
+#             prefs.pl, if globals.pl is split up. e.g. 'user_css_enable',
+#             'display_search_criteria', 'bannerhtml', 'useldap'
+#
+# pref_data_type - string indicating data type of this pref. List of valid
+#                  pref data types will be stored in globals.pl, or
+#                  something like a prefs.pl, if globals.pl is split
+#                  up. e.g. 'string', 'number', 'boolean', 'url',
+#                  'enum'. (Could be new DB table - but is that overkill>)
+#
+# pref_description - Description of this pref to be used in GUIs etc.
+#
+# pref_default - The default value as distributed with Bugzilla.
+#
+# pref_def_data1 - If the preference has extra data associated with it, then 
+# pref_def_data2   these are the defaults, as distributed with Bugzilla.
+#
+
+$table{pref_defs} = 
+    'pref_defs_id mediumint not null auto_increment primary key ,
+     pref_group_id mediumint  not null ,
+     pref_display_order smallint not null ,
+     pref_display_name varchar(50) not null ,
+     pref_name varchar(50) not null ,
+     pref_data_type varchar(20) not null ,
+     pref_description varchar(255) ,
+     pref_default mediumtext not null,
+     pref_def_data1 mediumtext ,
+     pref_def_data2 mediumtext ,
+
+     index(pref_group_id) ,
+     index(pref_display_order) ,
+     index(pref_name)';
+
+#
+# Bugzilla Prefs table
+#
+# For a pref_type of 'user', there will be an item in this table with a
+# pref_type_id == -1 which indicates the default value for the installed
+# system (which may be different to the Bugzilla distribution default).
+#
+# For a pref_type of 'system', the pref_type_id is not used
+#
+#
+# Column specs
+#-------------------------------------
+# pref_defs_id - What sort of pref is this?
+#
+# pref_type_id - DB ID related to the pref_type field. e.g. if the type is
+#                'user', then this pref_type_id will be the user_id
+#
+# pref_type - The 'type' of preference this is. An enum of
+#             strings. Initially 'user', or 'system', but there may be more
+#             in the future. (user groups?. per product (display) prefs?
+#             Valid pref types will be stored in globals.pl, or something
+#             like prefs.pl, if globals.pl is split up.
+#
+# pref_value - The actual value, as defined by the pref_data_type in the
+#              pref_defs table
+#
+# pref_data1 - Extra data associated with this preference
+#
+# pref_data2 - Extra data associated with this preference
+#
+#
+# Any indexes needed?
+#
+$table{prefs} = 
+    'pref_defs_id mediumint not null ,
+     pref_type_id mediumint ,
+     pref_type varchar(20) not null ,
+     pref_value mediumtext not null ,
+     pref_data1 mediumtext,
+     pref_data2 mediumtext';
+
+
+
 
 ###########################################################################
 # Create tables

Comment 10

[Matthew Tuck [:CodeMachine]]

Currently lots of stuff is shoved into the versioncache so things don't need to
be read over.

As for shutdownhtml, that could be in localconfig, although a template might be
another option.

Comment 11

[Dave Miller [:justdave]]

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 12

[Matthew Tuck [:CodeMachine]]

And the header and footer are now templates rather than params.

Comment 13

[Matthew Tuck [:CodeMachine]]

Some of the params should probably go to localconfig, to handle the situation
where you have multiple installations sharing a database (supporting a
compatible schema).

In particular, urlbase, and possibly cookiepath.

Comment 14

[Dave Miller [:justdave]]

*** Bug 184751 has been marked as a duplicate of this bug. ***

Comment 15

[Dave Miller [:justdave]]

We're not putting the params in the database.  Too much of that stuff needs to
be outside of the database for everything else to work properly.  The original
reason given was so it could be more expansible...  well, that's been done,
because it's now stored in a two-layer hash instead of a flat file.  If you
think specific params need to be in the database, for some reason, file a bug
for that param specifically..

We'll just use this for the multi-panel thing.

Comment 16

[Erik Stambaugh]

Attachment: Tabifies editparams

I didn't realize the patch should be attached to this bug (the earlier summary
of this bug was to put params in the database and tabify editparams)

I originally attached this to bug 184751.

This patch adds a tabbed interface to editparams.cgi

Possible issues with this patch:

1. Some of the tab categorizations may be contested.
2. The look is slightly different from userprefs.cgi's tabs, since there are so


   many and it's important to distinguish the individual tabs
3. doeditparams.cgi had to be changed to skip over unspecified params.
   It doesn't appear to break anything.
4. Someone else may have already been working on this (oops!)

I'm sure there are other issues.  Have at it.

Comment 17

[Dave Miller [:justdave]]

We have a patch !!!!!

discussion?   I really like the interface he gave it.  We need to discuss what
the tab names will be and which params go on which tabs.

Comment 18

[Erik Stambaugh]

Attachment: Tabified params

Changes:

1. multi-select params can be cleared out (the previous patch broke that)
2. 'version' has been removed per suggestion from justdave
3. lots of html filters added to the template

Comment 19

[Erik Stambaugh]

Attachment: Tabified parameters

The last patch had a whoops in it that broke the 'General' tab.  Everything
looks fine now.

Comment 20

[Dave Miller [:justdave]]

Attachment 108972 [details] [diff] is now live on http://landfill.bugzilla.org/bzdave/editparams.cgi
I've granted tweakparams to .* so everyone can play.

Comment 21

[timeless]

1. tabs suck, i ended up looking at the wrong tab because the rows swapped on me.
Please consider some method of making them all fit on one line. or perhaps take
apple's approach and use a select menu.

2. i don't think normal admins care what the internal name for a field is. i'd
deemphasize it (even display:collapsed by default, if someone wants to see it,
they can poke css to show it).

3. when is this stuff:
  usetargetmilestone  Do you wish to use the Target Milestone field?
Reset On Off
nummilestones If using Target Milestone, how many milestones do you wish to appear?
Reset
curmilestone If using Target Milestone, Which milestone are we working toward
right now?
- becoming per product? and how will that affect this form?

Comment 22

[Gervase Markham [:gerv]]

I agree with Timeless' point 1) - surely we can get them all on one line. And
re: point 2, each param name should have a short description ("Shadow Database
Name") to be used in the UI.

I have several other comments, but don't have time to write them at just this
second. The main thing, though, is that editparams used to suck because the UI
is autogenerated. Even now that it's all categorised, it's still autogenerated,
and the descriptions remain in defparams.pl, where they are not localisable. 

If we are going to do this _right_, we should design and implement proper, fixed
UI panes for each tab, which can be localised appropriately. We can then group
related parameters, and generally provide a much better UI experience. This
might mean getting rid of flat mode - fine, it sucks.

Gerv

Comment 23

[Dave Miller [:justdave]]

How many is too many tabs to fit on one line?  Right now there's 9 total tabs,
if the params are split up enough to be useful in finding things, I can foresee
there being 12 to 15.  I don't think that would reasonably fit on one line
without causing horizontal scrolling.

Comment 24

[Erik Stambaugh]

The idea for this was to make it operate like the user prefs menu so there's
some uniformity.  Unfortunately, I haven't used an Apple since early MacOS 8, so
I'm not sure what you mean by a select menu.  I'll look around for it.

I really hate the idea of making static templates for these.  What I'd rather do
is put tab descriptions, field names, field descriptions, and alternate option
names into another template (say, like field-descs.html.tmpl) that can be looked
up as necessary.  If it's not in the template it can fall back on whatever's in
defparams.

The tabs should break everything into digestable little chunks, which means,
like justdave said, there will eventually be quite a few tabs, so fitting them
all on one row seems impractical.  I played with the idea of using a scrollable
tab-bar, that is, fakey-scrollable with little 'next' and 'previous' buttons on
the ends, but while it's less cluttered on-screen, it's _very_ counterintuitive.

The bit where the row of tabs pops down is standard tab behavior in my
experience.  I'm not saying it's good (tabs are, in fact, somewhat yucky), but
it shouldn't shock that many people.

Flat mode, yes, sucks.  It's included because it's not hard to generate and
would ease the transition for people who are upgrading.  That and some people
might find it nice on a brand new install to have a serial list of params to
plow through.  I wouldn't, but someone else might.  I won't weep if it goes away
altogether.

Comment 25

[Erik Stambaugh]

re: comment 21

Oh, wait-- I'm being stupid!  You're talking about having the menu options in a
select box, right?  I thought 'select menu' was an Apple-ism, like 'chooser'.

It's not a terrible idea, but if I recall correctly, it either has to be
javascript-reliant or have a 'submit' button sitting next to it, neither of
which I'm terribly keen on.  Even if it doesn't need either of those, select
boxes in HTML are more constraining than I'd like.

Comment 26

[timeless]

right on all counts. it's not pretty but it only suffers from the two
limitations you described instead of all the bugs you can find at iarchitect.

The alternative is to put the different tabs vertically instead of horizontally,
ala mozilla preferences.  imo this actually works better than the layout you're
currently toying with. each tab has a fixed width equal to the width of all
other tabs, and their positions don't really change.

Comment 27

[Dave Miller [:justdave]]

that's actually not a bad idea :)

Erik, can you make that happen?

Comment 28

[Erik Stambaugh]

Vertical isn't a bad idea at all.  It's one that has been sitting in the back of
my mind all this time.  My biggest problem with editparams is how wide the
screen is, though, and it's because the text input boxes and textareas are set
to 80 characters wide (though the observant will note I made the text inputs 60
chars in my patch).  Sticking the tabs on the side would force about 20-30% of
your screen real estate to be dedicated to navigation, all the way down.  That's
pretty intrusive.

It would work fine, though, if text entry boxes and textareas could be narrowed
down.  If not, I wouldn't advocate the side panel.

Comment 29

[Erik Stambaugh]

Attachment: Tabs on the left

This is for discussion purposes only-- I don't consider it ready for prime
time.  For one thing, the l10n thing hasn't been addressed.  But take a look at
it.  Kick the tires, etc..

Comment 30

[Gervase Markham [:gerv]]

> How many is too many tabs to fit on one line?  Right now there's 9 total tabs,
> if the params are split up enough to be useful in finding things, I can foresee
> there being 12 to 15.

After a certain point, the more tabs you have, the _harder_ it is to find
things, because the divisions will be smaller and so the chances of you picking
the wrong one are greater. I think the UI law about 7-9 being the right length
for a menu probably applies to these tabs as well.

> I really hate the idea of making static templates for these.

Why? This enables us to have the proper UI for each tab. Currently, each one is
just a long list of parameters, caged to a particular name - description -
control format. That's not the best way to present configuration information.
See Mozilla's (or any other app's) preferences panel - each one is specifically
designed for the preferences it contains. 

> The bit where the row of tabs pops down is standard tab behavior in my
> experience.  I'm not saying it's good (tabs are, in fact, somewhat yucky), but
> it shouldn't shock that many people.

The fact that it's a common piece of UI suckiness doesn't make it suck any less. :-)

> Flat mode, yes, sucks.  It's included because it's not hard to generate and
> would ease the transition for people who are upgrading.

How so? I don't believe it makes things easier to find for such people. And it
just leaves us with something to maintain. "It's not hard to do" is a bad
reason, on its own, for doing anything :-)

Gerv

Comment 31

[Erik Stambaugh]

re: comment 30

> After a certain point, the more tabs you have, the _harder_ it is to find
> things, because the divisions will be smaller and so the chances of you 
> picking the wrong one are greater. I think the UI law about 7-9 being the 
> right length for a menu probably applies to these tabs as well.

I'm starting to get used to the idea of side-tabs, which makes the interface a
good deal less cluttered and confusing.  I'm also considering the idea of a
sub-menu, just like Mozilla has.  It wouldn't be too much more work.

I won't accept that we have to keep our menu selections down below 7-9 just
because it would intimidate or confuse some end-users, though.  This is the
administrative interface after all, besides which is the fact that what lies
below (or at this point, to the side of) the menus is the intimidating part.

>> I really hate the idea of making static templates for these.

> Why? This enables us to have the proper UI for each tab. Currently, each one 
> is just a long list of parameters, caged to a particular name - description -
> control format. That's not the best way to present configuration information.
> See Mozilla's (or any other app's) preferences panel - each one is 
> specifically designed for the preferences it contains. 

The current setup with defparams is nice in my opinion because of its
hackability.  I'd prefer to extend the defparams model rather than replace it,
and I can't think of something besides needless flash that can be generated with
static pages and won't work with a few tweaks to what we have.

Unless, of course, we're looking at going in whole new directions with
editparams that aren't simply editing params.  I don't have a problem discussing
that, but I don't think it suits the problem at hand.

> The fact that it's a common piece of UI suckiness doesn't make it suck any 
> less. :-)

Well it makes it suck a *little* less because it's expected behavior, but it
doesn't change the fact that it sucks.

>> Flat mode, yes, sucks.  It's included because it's not hard to generate and
>> would ease the transition for people who are upgrading.

> How so? I don't believe it makes things easier to find for such people. And it
> just leaves us with something to maintain. "It's not hard to do" is a bad
> reason, on its own, for doing anything :-)

Some people want to have a gradual transition to new interfaces and would want
to fall back on something like this.  Others might really have some perverse
need for all params on one page.  I didn't say that "It's not hard to do" was my
only reason for including it.  Just that it helped justify it.

Comment 32

[Gervase Markham [:gerv]]

> I won't accept that we have to keep our menu selections down below 7-9 just
> because it would intimidate or confuse some end-users, though. 

It's not about being intimidating or confusing. It's about being _usable_.
Usability isn't just something that applies to the computer-illiterate; it's
about software being intuitive and understandable for those at whom it's aimed.
In this case, it's Bugzilla sysadmins - but their brains work the same way as
everyone else's, and so HCI maxims should not be lightly cast aside.

> The current setup with defparams is nice in my opinion because of its
> hackability.

Yes, it's easy to add a param. (One might suggest that this is why we have so
many useless ones.) But I would maintain that it's far less usable than it could
be, and one thing it _definitely_ isn't is localisable. 

Basically, if you don't convert it to a template-pane-based UI, I'll have to
come along and do it later, because admin templatisation and localisability is a
2.18 goal :-) I have loads on my plate, so I'd much prefer it if you did it, but
if you don't want to, fair enough.

Gerv

Comment 33

[Erik Stambaugh]

re: comment 32

> It's not about being intimidating or confusing. It's about being _usable_.
> Usability isn't just something that applies to the computer-illiterate; it's
> about software being intuitive and understandable for those at whom it's 
> aimed. In this case, it's Bugzilla sysadmins - but their brains work the same 
> way as everyone else's, and so HCI maxims should not be lightly cast aside.

I'm not sure if I'm lightly casting them aside.  I just don't want to limit the
number of menu items just because there's a rule that says that's what you do.

I agree that limiting the number of items is better than not limiting them,
however.  A tradeoff has to be made between an intimidating panel and an
intimidating menu.  What I'd like to see is sub-menus, much like Mozilla has. 
That should be a lot more navigable.

> Yes, it's easy to add a param. (One might suggest that this is why we have so
> many useless ones.) But I would maintain that it's far less usable than it 
> could be, and one thing it _definitely_ isn't is localisable. 
>
> Basically, if you don't convert it to a template-pane-based UI, I'll have to
> come along and do it later, because admin templatisation and localisability is 
> a 2.18 goal :-) I have loads on my plate, so I'd much prefer it if you did it, 
> but if you don't want to, fair enough.

I'm not refusing to make static pages for editparams.  What I'm trying to do is
get you to convince me that it's necessary.

This patch templatizes the UI, but also keeps it easy to add params or move them
to another tab.  What I'd like to do is make the text content localizable by
putting it into a lookup template like field-descs.  That keeps the localized
content in one place just like the param definitions, and adding a new tab or
param is *almost* as easy as the corrent defparams-only method.

I guess I just want to know why that's such a bad idea.

Comment 34

[Gervase Markham [:gerv]]

> I'm not sure if I'm lightly casting them aside.  I just don't want to limit 
> the number of menu items just because there's a rule that says that's what you
> do.

You should limit the number of items because the reasoning behind the rule has
been found to be solid, and it's a well-respected guideline in the UI design
community. 

> I agree that limiting the number of items is better than not limiting them,
> however.  A tradeoff has to be made between an intimidating panel and an
> intimidating menu.  What I'd like to see is sub-menus, much like Mozilla has. 
> That should be a lot more navigable.

Maybe I don't understand your current vision of the UI. Where is the panel, and
where is the menu?

If we have enough configuration parameters that we need sub-menus, then we need
to simplify the configuration. Sub-menus are bad when used as a way of hiding
lots of top-level menus by "grouping" because you can't see all the choices
up-front. It's just an excuse to avoid improving your UI design.

> I'm not refusing to make static pages for editparams.  What I'm trying to do 
> is get you to convince me that it's necessary.

Well, we need it for localisation purposes, and to make the product more usable. 

> to another tab.  What I'd like to do is make the text content localizable by
> putting it into a lookup template like field-descs.  

Why would we want to localise all our other UI one way, and this bit another
way? A field-descs-type system is designed for very short, often-used words or
pairs of words, not for used-once sentences and paragraphs.

Gerv

Comment 35

[Erik Stambaugh]

re: comment 34

> You should limit the number of items because the reasoning behind the rule has
> been found to be solid, and it's a well-respected guideline in the UI design
> community. 

OK.  I really don't want to let this bug log degrade into a design philosophy
argument.  I'm trying to work toward that guideline, but I guess the reason I'm
being vocal about this is that I anticipate seeing this patch rejected if it
has, say, eight or nine menu items instead of six or seven.

Bear in mind that the purpose of this patch is to make the params be
multi-panel.  If the way we do params must get an overhaul, we're talking about
something else.  Or am I wrong?

> Maybe I don't understand your current vision of the UI. Where is the panel,
> and where is the menu?

My latest patch has a non-tabbed menu on the left-hand side.  The landfill link
doesn't appear to show that anymore.  I threw the patch together to kind of
humor justdave, but I found that I like it a mot more than tabs across the top.

I'll see if we can dig up a URL that shows it.

> If we have enough configuration parameters that we need sub-menus, then we
> need to simplify the configuration. Sub-menus are bad when used as a way of
> hiding lots of top-level menus by "grouping" because you can't see all the
> choices up-front. It's just an excuse to avoid improving your UI design.

If they fall into logical groups, I don't see how this makes things any more
difficult.

> Well, we need it for localisation purposes, and to make the product more
> usable. 
>
> Why would we want to localise all our other UI one way, and this bit another
> way? A field-descs-type system is designed for very short, often-used words or
> pairs of words, not for used-once sentences and paragraphs.

I guess I've been clinging to the idea of keeping all of it in defparams, which
is something that I like, but I guess it's not right for localization purposes,
since we then have to define all of the text twice.

Ugh, OK, so you've talked me into it.

Now I want to get going with these templates.  I would like to hear what
everyone thinks about the menu item categories.  The current patch isn't the
right way to do it, I think everyone will agree.

Comment 36

[Dave Miller [:justdave]]

I for one, happen to like that patch.

How about if we do it this way:

The description item within each parameter disappears from the defparams.pl file
completely.  The templates set the description based on the short parameter
name.  That way it keeps the parameter system sort of in line with how it is
now, but makes the descriptions localizable.

It seems to me with the way everything is moving towards modules that there may
be other ways besides web pages to access the params in the future (command-line
utility?).  Why not go ahead and make a single no-output template that does the
param-name to description mapping, so that can be used from whatever system is
being used without having to depend on the output format?  Better than having to
change the templates for every ctype any time you change a description.

Comment 37

[Gervase Markham [:gerv]]

OK, I'll buy Dave's solution for the localisation, although I'm not convinced
that the command-line param editing client will ever happen. :-)

I still think we should have separate tabs with properly-designed UIs, though,
and if I get around to it I will implement that in the future. But it can still
use the above mechanism.

Gerv

Comment 38

[Jason Pyeron]

I think either the name of this bug should reflect the params->DB issue, so I 
can mark bug 208680 a duplicate of this one or move the DB issues to bug 208680.

Comment 39

[Jouni Heikniemi]

Comment on attachment 108972 [details] [diff] [review]
Tabified parameters

Bitrotten. It touches all the parameters, so it rots everytime somebody adds a
new one or makes a significant change. What a lovely patch. ;-)

Comment 40

[Jouni Heikniemi]

Comment on attachment 109043 [details] [diff] [review]
Tabs on the left

The same goes for this.

Comment 41

[Dave Miller [:justdave]]

OK, with the amount of things that are essentially "plugins" that are going to
wind up having parameters that need to be set, in thinking about the best way to
get plugins to be able to insert params, I decided the best way to handle that
is to create a plugin directory for the params, with a perl module that has
nothing but param defaults and check routines.  And since it goes along with
this so beautifully, I gave in and accepted Gerv's idea of having static
templates for the params UI.  There would be a params directory which contains
the templates for all the tabs.  (I'm using admin/params for this in my mockup)

The main NavBar on the left (or top, or wherever we put it?) would scan that
directory using the Directory plugin that comes with TT, and grab the titles,
descriptions, and sort keys out of each template in that directory to build the
navbar.  I have 90% of the UI infrastructure (not all of the tabs themselves)
implemented already because I wanted a good example to show.  It's running
through page.cgi at the moment because that was a quick easy way to play with
the templates :)

Have a look and tell me what you think:
http://landfill.bugzilla.org/bz46296/page.cgi?id=editparams.html

I think the colors suck, we can screw with the CSS later. :)  I'm looking at
function right now.

Comment 42

[Gervase Markham [:gerv]]

Dave: this looks great. :-) A couple of thoughts:

- Do you think we could have nested pages using subdirectories? For example,
LDAP could be below User Authentication.

- How is the system going to decide what order to put the "tabs" (down the side
is great, by the way) in?

- I love what you are doing with the languages UI, but should we be writing
detailed instructions and troubleshooting stuff in the docs, and linking them,
rather than putting them on each tab?

I take it that detailed feedback on text, arrangement and what goes where can
wait until the patch? ;-)

Gerv

Comment 43

[Dave Miller [:justdave]]

(In reply to comment #42)
> - Do you think we could have nested pages using subdirectories? For example,
> LDAP could be below User Authentication.

Yes, I think this is a good idea...  going along with that, how about if we
allow a group to be declared for each panel, and you have to be a member of that
group for that panel to show up in the menu on the left.  What benefit does that
give us?  Products, groups, keywords, etc, can all wind up using the same UI. :)
 (That's probably down the road a bit, though).  We have to totally rewrite half
of the admin stuff to be templatized anyway, so why not? :)

> - How is the system going to decide what order to put the "tabs" (down the
> side is great, by the way) in?

Sortkeys.  They'll be in the same place with the titles and descriptions.

> - I love what you are doing with the languages UI, but should we be writing
> detailed instructions and troubleshooting stuff in the docs, and linking them,
> rather than putting them on each tab?

You've read http://catb.org/~esr/writings/cups-horror.html , right?  I tend to
agree with him. :)  And you know damn well people usually hit the docs as a last
resort, so by having the instructions right there, it'll probably save us lots
of headaches on the newsgroup, too :)

> I take it that detailed feedback on text, arrangement and what goes where can
> wait until the patch? ;-)

Sure ;)

Comment 44

[Gervase Markham [:gerv]]

I've read cups-horror - but having lots of text obscuring the function you need
is also bad UI.

I think we can reduce the text on that particular page by just putting
instructions on there, and shifting troubleshooting stuff out. We can also put
the explanations below the controls, so someone coming there to change something
they know about isn't digging through pages of prose.

Gerv

Comment 45

[Dave Miller [:justdave]]

Yeah, moving the controls to the top sounds like a good idea.  There's very
little troubleshooting info there.  "If it's not here, try running checksetup.pl
again".  That barely takes any space at all.  We can screw with the wording on
everything after I get the infrastructure done. :)  Hopefully I'll have a patch
up tonight or tomorrow.

Comment 46

[Dave Miller [:justdave]]

*** Bug 259159 has been marked as a duplicate of this bug. ***

Comment 47

[Dave Miller [:justdave]]

And as much as I hate to say so, this isn't going to make 2.20 (freeze in 2 days)

Comment 48

[Mudi Obada]

Can I set a hyperlink to individual comments? As in see Comment #2, Just like
when i say Bug #46296 ?

Comment 49

[tputz]

test

Comment 50

[Max Kanat-Alexander]

*** Bug 286341 has been marked as a duplicate of this bug. ***

Comment 51

[laurent]

Attachment: Législation

Comment 52

[info]

testcomment cause of evaluation of bugzilla

Comment 53

[Tom Klipps]

TEST TEST
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">
<!-- do nothing -->
<xsl:template match="x/y/z[a/@B='@c/']">
</xsl:template>
<!-- copy everything else exactly how it is -->
<xsl:template match="@*|node()">
  <xsl:copy>
    <xsl:apply-templates select="@*|node()"/>
  </xsl:copy>
</xsl:template>
</xsl:stylesheet>

Comment 54

[Frédéric Buclin]

I have started working on this bug. Let's see how far I can go. :)

Comment 55

[Frédéric Buclin]

Attachment: patch, v1

Fully fonctional patch.

- defparams.pl has been removed and splitted in Bugzilla/Config/*.pm modules;
- doeditparams.cgi has been removed and merged with editparams.cgi.
- parameter descriptions are now in the new admin/params/*.html.tmpl templates.

Comment 56

[Frédéric Buclin]

Attachment: patch, v1.1

This updated patch includes panel sortkeys. No other changes.

Comment 57

[Frédéric Buclin]

Attachment: patch, v1.2

bug 310982 has been checked in meanwhile. Unbitrotten patch.

Comment 58

[:glob ✱]

excellent :)

however i think it would be more intuitive to have all sections loaded on the
same page and use divs and javascript to show/hide the active page -- that way
changing sections won't revert edits.

Comment 59

[Joel Peshkin]

Comment on attachment 199242 [details] [diff] [review]
patch, v1.2

There is some really funky html here.  Fix that and the r+ will be a rubber
stamp.

Comment 60

[Frédéric Buclin]

Attachment: patch, v1.3

Fix bugs in the HTML code

Comment 61

[Dave Miller [:justdave]]

/me dances in the streets

Thanks, Fred, this has been a long time coming :)

Comment 62

[Frédéric Buclin]

Removing defparams.pl;
/cvsroot/mozilla/webtools/bugzilla/defparams.pl,v  <--  defparams.pl
new revision: delete; previous revision: 1.167
done
Removing doeditparams.cgi;
/cvsroot/mozilla/webtools/bugzilla/doeditparams.cgi,v  <--  doeditparams.cgi
new revision: delete; previous revision: 1.36
done
Checking in editparams.cgi;
/cvsroot/mozilla/webtools/bugzilla/editparams.cgi,v  <--  editparams.cgi
new revision: 1.28; previous revision: 1.27
done
Checking in Bugzilla/Config.pm;
/cvsroot/mozilla/webtools/bugzilla/Bugzilla/Config.pm,v  <--  Config.pm
new revision: 1.49; previous revision: 1.48
done
RCS file: /cvsroot/mozilla/webtools/bugzilla/Bugzilla/Config/Admin.pm,v
done
Checking in Bugzilla/Config/Admin.pm;
/cvsroot/mozilla/webtools/bugzilla/Bugzilla/Config/Admin.pm,v  <--  Admin.pm
initial revision: 1.1
done
RCS file: /cvsroot/mozilla/webtools/bugzilla/Bugzilla/Config/Auth.pm,v
done
Checking in Bugzilla/Config/Auth.pm;
/cvsroot/mozilla/webtools/bugzilla/Bugzilla/Config/Auth.pm,v  <--  Auth.pm
initial revision: 1.1
done
RCS file: /cvsroot/mozilla/webtools/bugzilla/Bugzilla/Config/BugChange.pm,v
done
Checking in Bugzilla/Config/BugChange.pm;
/cvsroot/mozilla/webtools/bugzilla/Bugzilla/Config/BugChange.pm,v  <--  BugChange.pm
initial revision: 1.1
done
RCS file: /cvsroot/mozilla/webtools/bugzilla/Bugzilla/Config/BugFields.pm,v
done
Checking in Bugzilla/Config/BugFields.pm;
/cvsroot/mozilla/webtools/bugzilla/Bugzilla/Config/BugFields.pm,v  <--  BugFields.pm
initial revision: 1.1
done
RCS file: /cvsroot/mozilla/webtools/bugzilla/Bugzilla/Config/BugMove.pm,v
done
Checking in Bugzilla/Config/BugMove.pm;
/cvsroot/mozilla/webtools/bugzilla/Bugzilla/Config/BugMove.pm,v  <--  BugMove.pm
initial revision: 1.1
done
RCS file: /cvsroot/mozilla/webtools/bugzilla/Bugzilla/Config/Common.pm,v
done
Checking in Bugzilla/Config/Common.pm;
/cvsroot/mozilla/webtools/bugzilla/Bugzilla/Config/Common.pm,v  <--  Common.pm
initial revision: 1.1
done
RCS file: /cvsroot/mozilla/webtools/bugzilla/Bugzilla/Config/Core.pm,v
done
Checking in Bugzilla/Config/Core.pm;
/cvsroot/mozilla/webtools/bugzilla/Bugzilla/Config/Core.pm,v  <--  Core.pm
initial revision: 1.1
done
RCS file: /cvsroot/mozilla/webtools/bugzilla/Bugzilla/Config/DependencyGraph.pm,v
done
Checking in Bugzilla/Config/DependencyGraph.pm;
/cvsroot/mozilla/webtools/bugzilla/Bugzilla/Config/DependencyGraph.pm,v  <-- 
DependencyGraph.pm
initial revision: 1.1
done
RCS file: /cvsroot/mozilla/webtools/bugzilla/Bugzilla/Config/GroupSecurity.pm,v
done
Checking in Bugzilla/Config/GroupSecurity.pm;
/cvsroot/mozilla/webtools/bugzilla/Bugzilla/Config/GroupSecurity.pm,v  <-- 
GroupSecurity.pm
initial revision: 1.1
done
RCS file: /cvsroot/mozilla/webtools/bugzilla/Bugzilla/Config/L10n.pm,v
done
Checking in Bugzilla/Config/L10n.pm;
/cvsroot/mozilla/webtools/bugzilla/Bugzilla/Config/L10n.pm,v  <--  L10n.pm
initial revision: 1.1
done
RCS file: /cvsroot/mozilla/webtools/bugzilla/Bugzilla/Config/LDAP.pm,v
done
Checking in Bugzilla/Config/LDAP.pm;
/cvsroot/mozilla/webtools/bugzilla/Bugzilla/Config/LDAP.pm,v  <--  LDAP.pm
initial revision: 1.1
done
RCS file: /cvsroot/mozilla/webtools/bugzilla/Bugzilla/Config/MTA.pm,v
done
Checking in Bugzilla/Config/MTA.pm;
/cvsroot/mozilla/webtools/bugzilla/Bugzilla/Config/MTA.pm,v  <--  MTA.pm
initial revision: 1.1
done
RCS file: /cvsroot/mozilla/webtools/bugzilla/Bugzilla/Config/PatchViewer.pm,v
done
Checking in Bugzilla/Config/PatchViewer.pm;
/cvsroot/mozilla/webtools/bugzilla/Bugzilla/Config/PatchViewer.pm,v  <-- 
PatchViewer.pm
initial revision: 1.1
done
RCS file: /cvsroot/mozilla/webtools/bugzilla/Bugzilla/Config/Query.pm,v
done
Checking in Bugzilla/Config/Query.pm;
/cvsroot/mozilla/webtools/bugzilla/Bugzilla/Config/Query.pm,v  <--  Query.pm
initial revision: 1.1
done
RCS file: /cvsroot/mozilla/webtools/bugzilla/Bugzilla/Config/ShadowDB.pm,v
done
Checking in Bugzilla/Config/ShadowDB.pm;
/cvsroot/mozilla/webtools/bugzilla/Bugzilla/Config/ShadowDB.pm,v  <--  ShadowDB.pm
initial revision: 1.1
done
RCS file: /cvsroot/mozilla/webtools/bugzilla/Bugzilla/Config/UserMatch.pm,v
done
Checking in Bugzilla/Config/UserMatch.pm;
/cvsroot/mozilla/webtools/bugzilla/Bugzilla/Config/UserMatch.pm,v  <--  UserMatch.pm
initial revision: 1.1
done
RCS file: /cvsroot/mozilla/webtools/bugzilla/skins/standard/params.css,v
done
Checking in skins/standard/params.css;
/cvsroot/mozilla/webtools/bugzilla/skins/standard/params.css,v  <--  params.css
initial revision: 1.1
done
RCS file:
/cvsroot/mozilla/webtools/bugzilla/template/en/default/admin/params/admin.html.tmpl,v
done
Checking in template/en/default/admin/params/admin.html.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/admin/params/admin.html.tmpl,v
 <--  admin.html.tmpl
initial revision: 1.1
done
RCS file:
/cvsroot/mozilla/webtools/bugzilla/template/en/default/admin/params/auth.html.tmpl,v
done
Checking in template/en/default/admin/params/auth.html.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/admin/params/auth.html.tmpl,v
 <--  auth.html.tmpl
initial revision: 1.1
done
RCS file:
/cvsroot/mozilla/webtools/bugzilla/template/en/default/admin/params/bugchange.html.tmpl,v
done
Checking in template/en/default/admin/params/bugchange.html.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/admin/params/bugchange.html.tmpl,v
 <--  bugchange.html.tmpl
initial revision: 1.1
done
RCS file:
/cvsroot/mozilla/webtools/bugzilla/template/en/default/admin/params/bugfields.html.tmpl,v
done
Checking in template/en/default/admin/params/bugfields.html.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/admin/params/bugfields.html.tmpl,v
 <--  bugfields.html.tmpl
initial revision: 1.1
done
RCS file:
/cvsroot/mozilla/webtools/bugzilla/template/en/default/admin/params/bugmove.html.tmpl,v
done
Checking in template/en/default/admin/params/bugmove.html.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/admin/params/bugmove.html.tmpl,v
 <--  bugmove.html.tmpl
initial revision: 1.1
done
RCS file:
/cvsroot/mozilla/webtools/bugzilla/template/en/default/admin/params/common.html.tmpl,v
done
Checking in template/en/default/admin/params/common.html.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/admin/params/common.html.tmpl,v
 <--  common.html.tmpl
initial revision: 1.1
done
RCS file:
/cvsroot/mozilla/webtools/bugzilla/template/en/default/admin/params/core.html.tmpl,v
done
Checking in template/en/default/admin/params/core.html.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/admin/params/core.html.tmpl,v
 <--  core.html.tmpl
initial revision: 1.1
done
RCS file:
/cvsroot/mozilla/webtools/bugzilla/template/en/default/admin/params/dependencygraph.html.tmpl,v
done
Checking in template/en/default/admin/params/dependencygraph.html.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/admin/params/dependencygraph.html.tmpl,v
 <--dependencygraph.html.tmpl
initial revision: 1.1
done
RCS file:
/cvsroot/mozilla/webtools/bugzilla/template/en/default/admin/params/editparams.html.tmpl,v
done
Checking in template/en/default/admin/params/editparams.html.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/admin/params/editparams.html.tmpl,v
 <--  editparams.html.tmpl
initial revision: 1.1
done
RCS file:
/cvsroot/mozilla/webtools/bugzilla/template/en/default/admin/params/groupsecurity.html.tmpl,v
done
Checking in template/en/default/admin/params/groupsecurity.html.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/admin/params/groupsecurity.html.tmpl,v
 <--  groupsecurity.html.tmpl
initial revision: 1.1
done
RCS file:
/cvsroot/mozilla/webtools/bugzilla/template/en/default/admin/params/l10n.html.tmpl,v
done
Checking in template/en/default/admin/params/l10n.html.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/admin/params/l10n.html.tmpl,v
 <--  l10n.html.tmpl
initial revision: 1.1
done
RCS file:
/cvsroot/mozilla/webtools/bugzilla/template/en/default/admin/params/ldap.html.tmpl,v
done
Checking in template/en/default/admin/params/ldap.html.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/admin/params/ldap.html.tmpl,v
 <--  ldap.html.tmpl
initial revision: 1.1
done
RCS file:
/cvsroot/mozilla/webtools/bugzilla/template/en/default/admin/params/mta.html.tmpl,v
done
Checking in template/en/default/admin/params/mta.html.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/admin/params/mta.html.tmpl,v
 <--  mta.html.tmpl
initial revision: 1.1
done
RCS file:
/cvsroot/mozilla/webtools/bugzilla/template/en/default/admin/params/patchviewer.html.tmpl,v
done
Checking in template/en/default/admin/params/patchviewer.html.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/admin/params/patchviewer.html.tmpl,v
 <--  patchviewer.html.tmpl
initial revision: 1.1
done
RCS file:
/cvsroot/mozilla/webtools/bugzilla/template/en/default/admin/params/query.html.tmpl,v
done
Checking in template/en/default/admin/params/query.html.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/admin/params/query.html.tmpl,v
 <--  query.html.tmpl
initial revision: 1.1
done
RCS file:
/cvsroot/mozilla/webtools/bugzilla/template/en/default/admin/params/shadowdb.html.tmpl,v
done
Checking in template/en/default/admin/params/shadowdb.html.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/admin/params/shadowdb.html.tmpl,v
 <--  shadowdb.html.tmpl
initial revision: 1.1
done
RCS file:
/cvsroot/mozilla/webtools/bugzilla/template/en/default/admin/params/usermatch.html.tmpl,v
done
Checking in template/en/default/admin/params/usermatch.html.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/admin/params/usermatch.html.tmpl,v
 <--  usermatch.html.tmpl
initial revision: 1.1
done
Checking in template/en/default/global/messages.html.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/global/messages.html.tmpl,v
 <--  messages.html.tmpl
new revision: 1.33; previous revision: 1.32
done
Checking in template/en/default/global/user-error.html.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/global/user-error.html.tmpl,v
 <--  user-error.html.tmpl
new revision: 1.131; previous revision: 1.130
done

Comment 63

[poo173]

Test

Comment 64

[bluefox78]

just a test 

Comment 65

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

Boy, this sure makes editparams harder for me to use.  I used to use Firefox's find in page feature to quickly find the param I was looking for.  Now I have to guess its category first.  Is there any option to decategorize, perhaps if only for a given page load?

Comment 66

[Frédéric Buclin]

(In reply to comment #65)
> to guess its category first.  Is there any option to decategorize, perhaps if
> only for a given page load?

myk, all parameters are displayed in the index: editparams.cgi?section=index

Comment 67

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

> myk, all parameters are displayed in the index: editparams.cgi?section=index

Hmm, that's good, but limited, since only parameter names are displayed, not parameter descriptions (which contain important text for matching in a search).

Comment 68

[Gervase Markham [:gerv]]

Can we use our new prefs architecture to give admins a pref for the layout? Alternatively, the tabs should be done client-side using JS (which we are now allowed to require for admin pages), and so we just have a little script which changes a CSS rule to "unroll" the page.

Gerv

Comment 69

[Max Kanat-Alexander]

Added to the Bugzilla 2.22 Release Notes in bug 322960.