Open
Bug 61992
Opened 24 years ago
Updated 10 years ago
Reducing duplicate typing in versions
Categories
(Bugzilla :: Administration, task, P3)
Bugzilla
Administration
Tracking
()
NEW
People
(Reporter: hansoneric, Unassigned)
References
Details
Each product has a version, at my company some products use the same versions as
other products, when this happens, alot of typing goes on. I was wondering if
it would be possible to have an option on the "Edit Version" screen to have a
pull down box with the words next to it "Use versions from: --- ", normally the
pull down box would be blank or null, but it would contain a list of other
products. Then when you hit the button next to it, you would get a seperate
table with the heading "Versions from Applications" (for example if you were
using applications version numbers also). Then at the bottom of the table would
be a button that would let you stop using applications versions.
The pull down list would be always present so you could include versions from
multiple components.
I figured this would just be stored in a list somewhere and Bugzilla would pull
the "versions" field from any components stored in the list. An array with a
default value of null or something.
Comment 1•24 years ago
|
||
*** This bug has been marked as a duplicate of 69262 ***
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → DUPLICATE
Reporter | ||
Comment 2•24 years ago
|
||
Reopening bug since this seems to be fundamentally different problem, or at
least approach to the problem.
I think all products should have thier own set of milestones/versions. However,
it would be nice to be able to "include" or "link" other product's m/v into
another.
For example I have a product "Can Opener". In bugzilla there are two products
"Can Opener Hardware" and "Can Opener Software". The will share major target
milestons (1.0, 2.0, 3.0, etc). However Software may have individual sub
milestones (.9, 1.3, etc) but still wants the Hardware milestones. So I imagine
in Software's list of m/v, there would be a "link" entry telling bugzilla to
include the versions from the Product "Can Opener Hardware".
I began implementing this but slowed down when all I could think of was a
special string that would show Bugzilla that it wasn't a real version, but a
link version (e.g. "::link::Can Opener Hardware::" in the version field of Can
Opener Software.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Comment 3•24 years ago
|
||
That's exactly what bug 69262 is about. Don't forget that in Bugzilla 3's
design, there are no special fields -- 'version', 'milestone' and 'product'
are merely user-defined fields that happen to have those names.
Reporter | ||
Comment 4•24 years ago
|
||
I was hoping this would be implemented (or bug 69262) before 2004 (estimated
time for bugzilla 3 by a posting to the bugzilla newgroup). I have been posting
to bug 69262 and it sounds different. I think my idea is easier to implement,
while bug 69262 would probably be best left as a design idea for B3.
Comment 5•23 years ago
|
||
Please elaborate in your own words what the difference between these two bugs is
... I don't see any.
We're targetting simultaneously released products for 3.X because that's where
it seemed it will most likely be fixed. Judging by the way development has
progressed since then we're not afraid of continuing schema changes on the 2.X
line, so maybe it will get done. It would certainly be nice but I'm trying to
balance it with lots of other things that would also be nice before then.
Generally enhancement request targetting is only my personal opinion on the
state of things, as most enhancements aren't "required". And if they aren't I
don't have too much influence in making people do stuff by a specific time, and
in the majority of cases I wouldn't want to try and make them not to do it
before then.
Maybe this will get done by then ... the team changes their mind about things as
members change their mind or more people get involved. And anyone can
contribute the code to do this.
Target Milestone: --- → Future
Reporter | ||
Comment 6•23 years ago
|
||
Mathew, please take a closer look. I believe there are good explanations on both
bugs. Here is a summary though:
I believe bug 69262 is a structural way in which we treat how fields (version
or milestones) relate to each. The bug seems to be about the structure of
bugzilla.
My bug is a superficial working fix. I want to be able to include Milestones
or Versions across Products, but also have each Product have its own "private"
set. Therefore you could have a master set of Milestones that are shared by all
Products (I.e. Product A shares Product B's Milestones, and only Product B needs
to be updated). But Products would each have thier own Milestones, maybe
minimilestones, I don't know.
The point being I think I, or someone else, could implement this functionality
before bugzilla 3. Bug 69262 seems specifically targeted toward Bugzilla 3.
Comment 7•23 years ago
|
||
-> Bugzilla product
Assignee: tara → justdave
Status: REOPENED → NEW
Component: Bugzilla → Administration
OS: Linux → All
Product: Webtools → Bugzilla
Hardware: PC → All
Version: other → unspecified
Comment 8•22 years ago
|
||
Reassigning all of my "future" targetted bugs to indicate that I'm not presently
working on them, and someone else could feel free to work on them. (sorry for
the spam if you got this twice, it didn't take right the first time)
Assignee: justdave → nobody
Updated•18 years ago
|
QA Contact: mattyt-bugzilla → default-qa
Updated•18 years ago
|
Target Milestone: Future → ---
Updated•16 years ago
|
Assignee: nobody → administration
Comment 9•10 years ago
|
||
I think this bug is unlikely to be implemented, because bug 69262, which allows Products to share Version or Milestone sets, will provide the right function for most users. Allowing them also to have their own private additional options would complicate things quite a bit, I'd imagine. (What happens if the shared set acquires a milestone which is already in one of the independent sets?)
Gerv
You need to log in
before you can comment on or make changes to this bug.
Description
•