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

RESOLVED WORKSFORME

Status

()

--
enhancement
RESOLVED WORKSFORME
17 years ago
5 years ago

People

(Reporter: jouni, Unassigned)

Tracking

Details

(Reporter)

Description

17 years ago
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

17 years ago
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.)
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 :)
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.
(Reporter)

Comment 4

17 years ago
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?
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.
(Reporter)

Comment 6

17 years ago
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?
(Reporter)

Comment 7

16 years ago
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.
(Reporter)

Comment 8

16 years ago
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. 
(Reporter)

Comment 9

14 years ago
Reassigning to nobody@bugzilla.org; 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.
Assignee: jouni → nobody
Summary: Default column list should be in localconfig → Default column list should be easier to configure (localconfig?)

Updated

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

Updated

12 years ago
Duplicate of this bug: 378861
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. :)
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → WORKSFORME

Comment 12

5 years ago
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

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

Comment 14

5 years ago
(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

5 years ago
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.
You need to log in before you can comment on or make changes to this bug.