Closed Bug 173133 Opened 22 years ago Closed 5 years ago

Additional level of categorization: sub-component

Categories

(Bugzilla :: Bugzilla-General, defect)

Product:
Bugzilla
Component:
Bugzilla-General
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: myk, Unassigned)

References

Details

Attachments

(2 files, 1 obsolete file)

same patch, fixed typo (legal_subcompontns, globals.pl)
44.43 KB, patch
Details | Diff | Splinter Review
patch for editcomponents.cgi
38.50 KB, patch
Details | Diff | Splinter Review 
Bugzilla should allow a third level of categorization besides just product and
component.  This might be called "sub-component" in the database, but could be
called something else in the interface using the standard available customizations.
Blocks: bz-zippy
I think that if we did this, the best way to handle this in the db would be to
remove the 'product' from the bugs table, and only use 'component'. Now that we
have ids, this would then be unique for all components, even those with the same
name, but different products.

The 'interesting' part will be refactoring the midair code to deal with changes
to components needing reorgs, not just products, and having two layers of
component selection when a product changes in a bug. Not to mention keeping
stuff as-is for existing installations.
If component IDs are unique across products, I don't see why product needs to be
a field in bugs, regardless of this RFE.
see also bug 43940
After re-reading bug 43940 I have half a mind to mark this a duplicate.  We're
proposing two ways of accomplishing the same thing, and if one of them gets
fixed, the other one is an automatic wontfix.  Should we just be discussing
which method is better all on the same bug?
OK, on further discussion on IRC, these aren't quite conflicting.

Resolving 173133 won't automatically wontfix 43940.  The other way around might.

However, this bug was filed because it was on the list of features Zippy wants,
and what it sounds like Zippy actually wants is another level above product, not
one below component.  Which would make this more along the lines of what it
appears bug 174298 is turning into, and likely easier to implement.
mattyt: Its simpler that way, since it avoids an extra sql query.

Can we get a use case from Zippy? If they're happy with what gerv is doing, I'd
really prefer that
> Its simpler that way, since it avoids an extra sql query.

What sort of query?  AFAICT there would not be any difference, except possibly
you need to join to the components table if you join to the products table, but
you often would be anyway, plus it's a simple index lookup.
Attached patch incomplete patch (obsolete) — — Splinter Review 
At long last, here's a preliminary attempt to port the 3rd-level category
changes that we did for Zippy back into Bugzilla.

This patch is somewhat incomplete...  this was compiled from a list of checkins
related to it that I kept in a note file here, and I'm pretty sure there's a
few important pieces missing here beside the editcomponents.cgi file, which is
also not included here yet.  (I'm tired, and that's the one file I didn't get
done screwing with yet, and wanted to give Mike a chance to play with what I've
done so far :)

I will continue on this tomorrow at some point and see if I can fill in the
rest of the pieces.
thanks Dave.  i'm currently playing with it.  woo hoo!  that's one massive
patch.  more to come after i get it running.  =P
small typo.  not done playing w/ it yet, though.  more to come.  :D
At last, the long lost missing piece of the original patch.

Oy, what a hack. :)  But it seems to work.  Would be really niced if this was
templatized, but it's not.
Attachment #124049 - Attachment is obsolete: true
Is this something I can patch to 2.17.4 as is and upgrade from 2.16.3?
And will I be able to easily upgrade to 2.18 with my existing database? 

Thanks,
Albert
We successfully patched 2.17.4 but there are some missing files and some minor
syntax errors.  I am tasked with recontributing our resulting source, and will
as soon as I can.

But yes, you can patch it to 2.17.4 pretty easily, but it'll take a lot of time
to do if you use what currently exists -- what I submit will help you save time.
 When do you think you would need it by, Albert?  I could have the diffs up here
in a couple of weeks.

Your 2.16.3 question would be best answered by someone else.
A couple weeks would work for me.  I figure I need to first upgrade to 2.17.4 
before trying this patch. My main concern is that the database structure for 
this bug is marked frozen for 2.18.

I'm also assuming one can "easily" move the existing 2-tier products/components
to fit into the new 3-tier structure?
the 3-tier structure is an addendum that doesn't require modification of 
existing structures.  as for the continuity of the db schema between 2.17.4 and 
2.18, i'd ask that question on irc for a speedy answer 
(irc://mozwebtools@irc.mozilla.org).

i'll try to get on that resubmission so you can have a patch ready by the time 
you are done upgrading to 2.17.4.
yeah, the way it was originally specced out, the bottom level is optional, and
if a component doesn't have any subcomponents defined, then it just ignores
them.  So this would basically add the capability to add subcomponents under
your existing components, if you wanted to.
Thanks for the speedy responses.  

Is it possible to push an existing product/component down a level?  So instead
of FOO->BAR product/component, I'd like to move it to PROD->FOO->BAR.
I've been looking at the db schema and realize this may not meet what I was
hoping for. While I'd like three levels, I'm looking for a higher "department"
level rather than a lower "subcomponent" level.  It's subtle, but the key
difference is that the version field is tied to the "product" level, which I was
going to treat as the "department" level.  Hence the version field won't work
that well.

I had considered using creating separate databases for each department and use
the movebugs approach.  But that's cumbersome for us, as we'd like easily
move/manage all bugs without having to deal with multiple logins, etc.

It would seem a department table that just had the name and product_id's would
be sufficient.

On a different note, this patch assumes the same set of data fields for both
subcomponent and component.  Enhancement requests such as bug #38922 will have
to be updated accordingly.
*** Bug 196489 has been marked as a duplicate of this bug. ***
What happens when someone wants a 4th and 5th level? Perhaps we should do this
in a way that allows an arbitrary number of levels that the admin decides, each
one being named by the admin?
Regarding comment #18, I've implemented a "parent-product" level.  
See bug #224208 for more info. 
Any objections to marking this (idle) bug as a duplicate of the (active) bug 224208?

(In reply to comment #22)
> Any objections to marking this (idle) bug as a duplicate of the (active) bug 
24208?

I'd agree with Joel that this could probably be resolved as a DUPE, now that we
have classifications. Do classifications provide all that this bug wants?


(In reply to comment #23)
> (In reply to comment #22)
> > Any objections to marking this (idle) bug as a duplicate of the (active) bug 
> 24208?
> 
> I'd agree with Joel that this could probably be resolved as a DUPE, now that
> we have classifications. Do classifications provide all that this bug wants?

No.  This bug wants subcomponents (level below components).  Although having
categories will help some of the folks who originally wanted this, it's still a
separate concept.
Summary: third level of categorization (i.e. product, component, sub-component) → Additional level of categorization: sub-component
Reassigning bugs that I'm not actively working on to the default component owner
in order to try to make some sanity out of my personal buglist.  This doesn't
mean the bug isn't being dealt with, just that I'm not the one doing it.  If you
are dealing with this bug, please assign it to yourself.
Assignee: justdave → general
QA Contact: mattyt-bugzilla → default-qa

This won’t happen since we already have 3 levels of categorization: Classifications, Products and Components. Basically we should use more Classifications.

Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → WONTFIX

(In reply to Kohei Yoshino [:kohei] from comment #26)

This won’t happen since we already have 3 levels of categorization: Classifications, Products and Components. Basically we should use more Classifications.

So if we want to have optional subcomponents in LibreOffice we should

  • move our Products to Classifications
  • move our Components to Products
  • populate Components with new categories
  • be able to make Components not be a required field (is this possible currently?)
  • update all the queries in our technical documentation due to the move operation

People would then start the reporting process by selecting a classification (I see this is how Red Hat does it).

Any tips on how to achieve this sort of a change and to avoid problems? The crucial thing is that Components then need to be optional, not required. Would this require hacking the BZ core?

We would possibly also want to allow multiple components per report, a functionality which was WONTFIXed in bug 178303. In the closed report, it is said that "you can use a custom multi-select field to implement this, if you really need to" - is there any reference implementation of this available?

Then you can probably use keywords instead, which can be optional and multiple. Some GitHub repositories use labels to do the same thing. See my BzDeck repo for example. The current UX of Bugzilla keywords is not great though.

(In reply to Kohei Yoshino [:kohei] from comment #28)

Then you can probably use keywords instead, which can be optional and multiple. Some GitHub repositories use labels to do the same thing. See my BzDeck repo for example. The current UX of Bugzilla keywords is not great though.

Hmm, thinking further, I would probably drop the requirement for multiple components per report and use meta bugs for any "global" categories. We want to keep the keywords to a minimum to avoid confusion. From the bug input UI perspective, it is more valuable to have a parent-child relationship for products + components.

The main motivation is the awkward, completely disconnected user experience of finding a relevant meta bug and then add it to Blocks. Thus a neat hierarchy is desired. Of course it would need a (local) rework of the Components UI element, turning it into a filterable list in bug creation/editing and searching.

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: