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.
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.
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.
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?
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.
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.
Reassigning to email@example.com; 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?)
Assignee: nobody → administration
QA Contact: mattyt-bugzilla → default-qa
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
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).
(Actually - current summary is fine. I was looking at the wrong tab when I made that suggestion. However, please re-open.)
(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.
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.