Move all select-type fields into custom fields framework

NEW
Unassigned

Status

()

Bugzilla
Bugzilla-General
--
enhancement
13 years ago
2 years ago

People

(Reporter: Max Kanat-Alexander, Unassigned)

Tracking

(Depends on: 2 bugs)

Dependency tree / graph

Details

(Reporter)

Description

13 years ago
Basically, we have a lot of select boxes on the show_bug page, right now.

The data for all those should probably be able to come from a single table.
(Reporter)

Updated

13 years ago
Depends on: 287336
(Reporter)

Comment 1

13 years ago
These changes should attempt to have no UI impact, by the way.

The UI changes can come in a later bug.
No longer depends on: 287336
(Reporter)

Updated

13 years ago
Depends on: 287337
This looks like a duplicate of bug 287322.  As I mentioned in that bug, we
should *not* move the values for these different fields into a single table,
because doing so prevents us from using foreign keys in the future to enforce
referential integrity, suboptimally expresses schema with data instead of
structure, and doesn't let us extend the values of various fields with
additional attributes that don't apply to every field.
(Reporter)

Comment 3

13 years ago
(In reply to comment #2)
> This looks like a duplicate of bug 287322.

  It's not; this is a more overarching bug including Version and Target Milestone.

  I would agree, though, "single table" is not actually necessary for the fixing
of this bug. The idea is just to put them into the Custom Fields framework.

Comment 4

6 years ago
Will this be also valid for Components ?
Then bug 757337 is a duplicate of this one.
Comment hidden (offtopic)
You need to log in before you can comment on or make changes to this bug.