Closed
Bug 317565
Opened 19 years ago
Closed 19 years ago
Field values should depend on the current products
Categories
(Bugzilla :: Administration, task)
Tracking
()
VERIFIED
DUPLICATE
of bug 106592
People
(Reporter: jessn, Unassigned)
Details
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322)
Build Identifier:
When a new product is made default data should be bootstrapped. I.e. with the fields values which are used today, but it should be possible to change the field values for that particular project only.
Reproducible: Always
Steps to Reproduce:
1. Create a product
2. Customize the fields values for that particular project only
Actual Results:
Step 2 is not possible.
Expected Results:
Customizing fields values for that particular project should be possible. An example on this is listed below:
Project 1: Blocker, Major, Minor, Enhancement
Project 2: High, Important, Normal
This feature could be used when different kinds of languages are used for the products and when priority and severity are different between products. Not all products need the same level of severities etc.
Comment 1•19 years ago
|
||
(In reply to comment #0)
>
> Actual Results:
> Step 2 is not possible.
This isn't quite true.
Components, versions and target milestones are product-dependent.
Comment 2•19 years ago
|
||
*** This bug has been marked as a duplicate of 106592 ***
Status: UNCONFIRMED → RESOLVED
Closed: 19 years ago
Resolution: --- → DUPLICATE
>> Components, versions and target milestones are product-dependent.
That is correct, but what about: Priority and Severity
These two are the primary field values this bug is about.
Comment 4•19 years ago
|
||
(In reply to comment #3)
>
> That is correct, but what about: Priority and Severity
> These two are the primary field values this bug is about.
I'm having a hard time imagining a solution where:
- people cannot agree on a set of values for priority and severity
- the differences between High, Important and Major (as an example) is so big that all three values have to be present.
Add the searching problems this will cause and I don't think this is a great idea. If you believe otherwise, feel free to contribute to bug #106592
You need to log in
before you can comment on or make changes to this bug.
Description
•