144177 - Default column list should be easier to configure (localconfig?)

Status: RESOLVED WORKSFORME

(Bugzilla :: Administration, task)

Description

[Jouni Heikniemi]

The default column list for buglist.cgi should IMO reside in localconfig, since
that is an installation-specific value and it would be easier to have the
configurables out of Perl files. Localconfig also has the settings for possible
platforms/OSes already, so this sort of stuff isn't totally alien to it.

Ccing justdave (as the Administration component owner) to hear his opinion:
should this be done? I can do the patch if this is considered a good idea.

Comment 1

[Andreas Franke (gone)]

IMO having it in localconfig is a step in the right direction. I had to change
the default list in my installation, too. Having a per-user default column list
so that the user can easily go back to his/her own default may or may not be a
desirable long-term enhancement. (See also bug 105110 for an attempt to provide
a per-query columnlist option.)

Comment 2

[Dave Miller [:justdave]]

For practicality I think it'd be a better fit for params, but there's no
mechanism in params for editing lists of things at the moment.  I think the
whole concept of sort order and columns to display needs an overhaul in Bugzilla
at the moment, but that's probably another story :)

Comment 3

[Matthew Tuck [:CodeMachine]]

Params already has default query which is a URL string and doesn't really suit. 
However, I'd much prefer it there than localconfig, which is more about
file-level configuration.  OSs and Platforms will be migrating out of
localconfig soon enough.

Comment 4

[Jouni Heikniemi]

I agree that params would be a better place for this, but I proposed localconfig
because I didn't consider the UI for administering this necessary.

Justdave, re comment 2: Do you think that overhauling the column list thingies
affects the need to have a configurable default for the column selection? 

MattyT, re comment 3: Where are the os and platform settings going to? Params?
Is there a bug on this? It would certainly be logical to have this kind of
things in one place.

So I see three alternatives:

1. Do nothing (and wait for changes in the system later)
2. Move the settings to localconfig (fairly easy)
3. Move the settings to params (takes a bit more work)

Which one?

Comment 5

[Matthew Tuck [:CodeMachine]]

The eventual policy will probably be most things will be in the database except
things which are:

- specifically low level (webservergroup)
- can't go in the database (database connection info, shutdownhtml)
- are best off as templates (header, banner and footer have been moved already)
- are best off being outside the database because you could have two
installations using the same database (urlbase definitely, cookiepath maybe)

The localconfig enumerations are going to the database, see bug #146104.  Most
of the params probably will be too, see bug #46296.  But params is the best
place for the moment I think.

Comment 6

[Jouni Heikniemi]

If params, we need to implement some new UI stuff for that. Do you know if work
for that is going on in any other bug?

Comment 7

[Jouni Heikniemi]

Apparently nobody knows. After thinking about this, I think the correct place is
where all the other params are. But since there are currently two places anyway,
I think it's better to choose localconfig now and move this to DB when all the
other enumerations move as well. 

Unless somebody objects and explains me why we'd want to work for a params
multiselect interface (while params are going to be in DB soon anyway), I'll
create a patch that moves this stuff into localconfig.

Comment 8

[Jouni Heikniemi]

If bug 146104 gets fixed in short order, we can dupe this to that. There's no
sense in bouncing default column lists back and forth. 

Comment 9

[Jouni Heikniemi]

Reassigning to [e-mail]; I don't have plans on implementing this in
the near future. 

The essence of this bug is easier configurability of default columns; whether
that's done in the DB or in the localconfig is a technical detail. The result
probably depends on the facilities available at the time this bug is fixed.

Comment 11

[Teemu Mannermaa (:wicked)]

There's a DEFAULT_COLUMN_LIST constant in Bugzilla/Constants.pm ever since bug 276842 moved them there. Recently it has been acceptable to keep certain things configurable as a constant and I believe this is one of them.

Certainly what's currently described in this bug is no better but if something easier is wanted somebody should probably morph this bug. :)

Comment 12

[Mark Clements]

Constants.pm will get overwritten with every update, so this is a pretty terrible place to have to make local configuration changes.

I don't have permission to re-open this bug, and I'm not sure it's sensible to log a new one, but I definitely think this is an issue which needs to be resolved.

Can someone please re-open and update the summary to "Default search columns should be user-configurable".

Any solution that doesn't involve editing core Bugzilla files and which doesn't cause the modifications to be lost when Bugzilla is upgraded would be acceptable (needn't be localconfig, though that seems like the most expedient solution).

Comment 13

[Mark Clements]

(Actually - current summary is fine.  I was looking at the wrong tab when I made that suggestion.  However, please re-open.)

Comment 14

[Frédéric Buclin]

(In reply to Mark Clements from comment #12)
> Constants.pm will get overwritten with every update

If you use bzr, changes will be merged when updating, not overwritten. localconfig is really not the right place to put such data.

Comment 15

[Mark Clements]

I'm not using bzr.  We cannot install it on our shared host.  Therefore, these files will be overwritten when we upgrade.

Whether or not localconfig is the right place to put this data is not really relevant (it should probably be removed from the bug summary, as it is not really the point of the bug - just one of several possible solutions - and seems to be causing people to focus on the wrong thing).

The point is that Constants.pm is the *wrong* place to put it, as it should be configurable without having to hack the Bugzilla code.