Open Bug 106592 Opened 23 years ago Updated 6 months ago

Field values for default fields should be able to be product-specific or product-inspecific

Categories

(Bugzilla :: Bugzilla-General, enhancement, P3)

2.15
enhancement

Tracking

()

People

(Reporter: myk, Unassigned)

References

(Depends on 1 open bug, Blocks 3 open bugs)

Details

Attachments

(1 file)

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.
Priority: -- → P3
Target Milestone: --- → Bugzilla 2.20
Blocks: 9410
Thats a idea how to change the database to supply defferend form for differend
components.
Blocks: 143411
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.
Summary: everything should be product-specific → everything should be able to be product-specific or product-inspecific
I like this idea. (DAGs could also be used for bug 43940: "Component trees".)
No longer blocks: 9410, 125300, 143411
Depends on: 9410, 125300, 202297
This should be much easier after bug 17453 checks in.
Severity: normal → enhancement
Depends on: bz-enums
Summary: everything should be able to be product-specific or product-inspecific → Field values should be able to be product-specific or product-inspecific
Assignee: justdave → mkanat
Target Milestone: Bugzilla 2.20 → Future
Blocks: 287336
Blocks: 287337
*** Bug 301139 has been marked as a duplicate of this bug. ***
*** Bug 317565 has been marked as a duplicate of this bug. ***
QA Contact: mattyt-bugzilla → default-qa
Blocks: 346841
Blocks: 163778
Target Milestone: Future → ---
Assignee: mkanat → general
Summary: Field values should be able to be product-specific or product-inspecific → Field values for default fields should be able to be product-specific or product-inspecific
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: