The platform, OS, and other fields that have the same set of possible values for an entire installation should be made product-specific.

I want to look at this some stage. Basically the way we need to do it for maximum flexibility is used inheritance - you can define a group of some type of value that is used by many or all products. This has been discussed previously on bug #69262.

In many sites, many products will only ever have one platform and one operating system. This is particularly true for in-house systems. For example, a firm's payroll system might run on Sun/Solaris. So it would be advantageous to allow the selection of a product to also (in these cases) also select the platform and the operating system.

Thats a idea how to change the database to supply defferend form for differend components.

I haven't read the schema attached above, but what I believe we need is as follows: We need the administrator to be able to define a directed acyclic graph with an all-product group at the top and single-product groups at the bottom. In between the administrator sets up a number of groups which can be defined in various ways by merging groups below. All groups except itself are implicit direct descendants of the all-product group. The question is how to deal with newly added products. We can just expect the admin to add them to appropriate defined groups manually, or we can include a checkbox for each intermediate group wherein we say whether that single-product group is a direct descendant of that group. Some visualisation would be nice here too. You then define a set of values and attach it to a product group and a field. If you want different values for each field you attach to the single-product groups, if you want product-inspecific fields you attach to the all-products group, if you want part way in between you attach to another group. You can attach to the all-product group, a single-product group and any other groups, all at the same time, and values are then inherited down into the individual products. To do lookups like this in SQL with just one statement we would therefore have no choice but to compute a descendant relation by maintaining a cache of the transitive closure of the direct descendant relation. One additional extra could be that when you are moving a bug between products, you complain about any value whose name exists but is defined elsewhere. For example, if I defined the milestones {M1,...} to apply to the product group {Prod1,Prod3} and separately {M1,...} to apply to the product group {Prod2,Prod3}, then Bugzilla would ask for confirmation if I moved a bug with a milestone of M1 from Prod1 to Prod3. There is no guarantee that M1 in one product group has a relationship to the M1 in another product group. On the other hand, if I defined the milestones {M1,...} to apply to the product group {Prod1, Prod2}, no confirmation would occur for this field if I moved a bug with a milestone of M1 from Prod1 to Prod2.

I like this idea. (DAGs could also be used for bug 43940: "Component trees".)

This should be much easier after bug 17453 checks in.

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

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