297616 - Replace all references to products and components with template terms

Status: RESOLVED WONTFIX

(Bugzilla :: User Interface, enhancement, P3)

Description

[A. Karl Kornel]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en) AppleWebKit/412 (KHTML, like Gecko) Safari/412
Build Identifier: 

My installation of Bugzilla isn't going to be geared towards tracking bugs in products, so the terms 
"product" and "category" don't really work, which means I've had to create custom templates (or modify 
the default template) for every file that publicly mentions the terms "product" or "category".  It occurs to 
me that it might be a good idea of these words were converted into template "terms", like the word "bug".  
Is such a thing advisable?

Reproducible: Always

Steps to Reproduce:




Again, this is coming from my copy of Bugzilla 2.18.1, but I'm pretty sure it applies to tip.

I'm also perfectly happy to take care of this.  If approved, are there any other words I should templatize?

Comment 1

[victory <[e-mail]>]

+1;
QA Contact, quips, etc also..

Comment 2

[A. Karl Kornel]

Obviously I need to add more information on this.  First of all, I was thinking of the following fields 
whose names should be converted into template terms:

* Product
* Category
* URL
* Status Whiteboard
* Hardware
* OS

The url, hardware, and os fields are not involved in any special processing that I know of, although 
hardware and OS list changes are run through checksetup.pl that's just for changing the list of possible 
values.  This is in comparison to a field like 'keywords', which has a special meaning within Bugzilla and 
can only contain specific values.  As for the status whiteboard field, although it is enabled/disabled by a 
Bugzilla parameter, it's not used as a special field inside Bugzilla (again, as far as I know).  The product 
& category fields can also have their labels changed to something user-defined.  For example, I'm using 
'category' and 'area'.  Of course, I'm open to discussion regarding additions to, and deletions from, the 
list above.

Also, before I continue it's worth noting that this discussion may already be taking place in a different 
bug, though I couldn't find any.  The primary bug tracking the ability to add custom free-form text 
fields (I don't have the # right now) doesn't seem to mention anything about modifying or deleting the 
standard fields that Bugzilla ships with (which includes the fields on the list above).  If there is a bug 
that covers making customizations or modifications to, or the ability to delete, one of the fields that 
comes on a fresh installation of Bugzilla, then this bug is probably a duplicate of that.  Otherwise, this 
bug may be relatively unique.

Now, back to my reasons why.  I got some comments from LpSolit a number of hours ago (by thw way, 
thanks very much for your comments LpSolit!).  You can read the discussion on IRC by going to 
<http://tinyurl.com/cx3e7>.  The relevant times are 00:45 to 01:05.

I was originally thinking, if there are different words that could be used for "Bug", why can't there be 
different words used instead of "product" and "component"?  You might not even be using Bugzilla as a 
means to track bugs in software.  You could use it as a general issue tracker, replacing "product" and 
"component" with appropriate terms to suit your application.  Yes, some features of Bugzilla would not 
be useful (such as CVS integration) and yes, documentation would have to be changed (examples 
reworked, certain resolutions and statuses slightly redefined, etc.), but it could work.

Assuming it does work, and that someone does decide to do this, then there are a large number of 
templates that must be changed.  In the end I had to modify 42 template files that had the terms 
"product" and/or "component".  Each of those 42 template files means more work when a new release 
comes out.  Of course, there will always be templates that will have to be reviewed and modified during 
an upgrade to a new release, but at least half of those 42 templates (probably more) were modified 
ONLY to change the "product" and "component" words.  If those terms were already templatized, the 
would be much less template code to review during an upgrade.

Anyway, that's my reasoning behind this bug.  Of course, I'm open to comments & questions (and votes 
8-).

In comment 3 I'll cover the movement to complete templatization, and I'll describe one problem I found.

Comment 3

[A. Karl Kornel]

In In comment 2 I explained in more detail my motivation behind this.  Of course, there is a problem.  
Well, at least one (I've only come up with one problem so far).

The terms that would be templatized appear in many different places, including non-template CGI 
code.  This includes .cgi files that have not been templatized (such as reports.cgi in 2.18.1), and it 
includes little text and HTML snippets that are generated by several scripts.  Those areas are beyond 
the reach of the Template Toolkit.  Although the non-templatized .cgi scripts can be templatized (I 
think there's a bug for that already), what about the little snippets of HTML that appear in many .cgi 
scripts?  Those little snippets would be completely out of reach.

My suggested solution to this problem would be to convert the terms hash from being defined in a 
template to being defined in a .pl file.  One default .pl file would provide the Bugzilla-approved 
definitions for the various terms, and that default .pl file would parse a second .pl file that contains 
customized templates, along with any new additions (the second file could be processed the same way 
the params file is processed).  The .pl files would be processes at the start of each script (like params), 
and the resulting %terms hash would be passed to the Template Toolkit whenever templates are 
processed.  I believe this would mean that all references to [% terms.bug %] (and the like) in templates 
now would not be affected.

Another solution would be to move every piece of HTML and text seen by the user into template files, 
no matter how small the piece may be.  Considering the number of additional templates this could 
create, I'd opt for the former option instead of the latter.

Anyway, does what I described above sound like a valid problem?  Any other solutions?

Comment 4

[Myk Melez [:myk] [@mykmelez]]

> First of all, I was thinking of the following fields whose names should be
> converted into template terms:
> 
> * Product
> * Category
> * URL
> * Status Whiteboard
> * Hardware
> * OS

A case could be made for product, component, and classification, but URL,
hardware, and OS all have specific, well-defined meanings, and status whiteboard
is an optional field.

If you need a freetext field like status whiteboard but with a different name,
the custom freetext fields feature being implemented in bug 287325 is your
solution (in fact, it's the solution for the whiteboard field too, which will be
made custom in bug 287323).

The fields with well-defined meanings, on the other hand, should retain their
meaning-specific names, but they should be made optional, so you can turn them
off if they don't work well in your environment.  Also custom fields with
similar functionality should be made available if you need something similar to
those fields, which is bug 287326 for single-select fields like OS and hardware
and bug 287328 plus some additional functionality for a field like URL.

> Another solution would be to move every piece of HTML and text seen by the
> user into template files, no matter how small the piece may be.

That's exactly what we should be doing.

> Considering the number of additional templates this could create,
> I'd opt for the former option instead of the latter.

How many occurrences are there?  I know the words appear a lot in code, but is
there really that much user-targeted text left in the Perl scripts (not
including the scripts whose output has yet to be templatized, of course)?

Comment 5

[A. Karl Kornel]

(In reply to comment #4)
> A case could be made for product, component, and classification, but URL,
> hardware, and OS all have specific, well-defined meanings, and status whiteboard
> is an optional field.
> 
> <<<snip>>>
> 
> The fields with well-defined meanings, on the other hand, should retain their
> meaning-specific names, but they should be made optional, so you can turn them
> off if they don't work well in your environment.  Also custom fields with
> similar functionality should be made available if you need something similar to
> those fields, which is bug 287326 for single-select fields like OS and hardware
> and bug 287328 plus some additional functionality for a field like URL.

Agreed.  I see no reason with shortening the list down to Product, Component, and Classification (a new 
field?).

> > Another solution would be to move every piece of HTML and text seen by the
> > user into template files, no matter how small the piece may be.
> 
> That's exactly what we should be doing.

Agreed.  I believe there are already bugs in the system for handling most of this.

> > Considering the number of additional templates this could create,
> > I'd opt for the former option instead of the latter.
> 
> How many occurrences are there?  I know the words appear a lot in code, but is
> there really that much user-targeted text left in the Perl scripts (not
> including the scripts whose output has yet to be templatized, of course)?
> 

Just to make sure I'm current, I looked at the tip as of 05:38 AM 17 June 2005 GMT, ignoring everything 
in contrib/ and docs/, as well as all .xml, .rdf, and .ics files, as well as importxml.pl and editparams.cgi 
(which had many, many mentions).  There were a lot fewer in tip than I expected!

* defparams.pl includes the terms in various parameter definitions

* quicksearch.html contains references to all terms, as does quicksearchhack.html

* sanitycheck.cgi refers to all terms, and when I say this I'm not talking about table/column names, I'm 
talking about error messages and status messages (as in "Checking for bugs with groups violating their 
product's group controls" on line 757).

In addition to those references, there is the fielddefs table in the database.  That has the terms 
"Product", "Component", and "Classification" pre-defined, with no admin-facing way (that I could find) 
for editing it, except maybe to modify checksetup.pl before running it for the first time.

Comment 6

[Marc Schumann [:Wurblzap]]

See also bug 218746.

Comment 7

[Frédéric Buclin]

*** This bug has been marked as a duplicate of 218746 ***

Comment 8

[Max Kanat-Alexander]

Actually, believe it or not, this bug is not completely a duplicate of bug 218746. The reason is that field_descs has one entry for each field, and the name is capitalized. However, the words "Product" and "Component" are used *everywhere* in Bugzilla, and not just as field names.

I've actually implemented a fix for this bug in 2.22, and I'm waiting on copyright release to bring it forward. But this is a case where this really belongs in the "terms" hash, and not in field_descs.

Comment 9

[Marc Schumann [:Wurblzap]]

Will this patch be prepared for localization? Meaning, will it take non-English languages transforming words for different cases into account?

Comment 10

[Max Kanat-Alexander]

The patch has "terms.Product" and "terms.product". It doesn't go quite as far as having aProduct and aproduct. I'm not sure that's quite as necessary, but we could do it, maybe.

Comment 11

[victory <[e-mail]>]

Attachment: patch for tip

I've converted some terms to use TT vars include these for 2.22.
I've finished to sync templates translation for Japanese,
 now I could grep terms.(product|component) to get the list :-)

there may be some places the translation don't have, though :-P

Comment 12

[Frédéric Buclin]

Comment on attachment 250935 [details] [diff] [review]
patch for tip

>+  "product" => "product",
>+  "Product" => "Product",
>+  "compoent" => "component",
>+  "Compoent" => "Component"


Two things come to mind:

1) Plural of some words 'foo' is not 'foos'. Obvious examples exist at least in french and german, and I suppose in english too.

2) I'm not a fan of all these terms.foo variables within templates.

Comment 13

[Max Kanat-Alexander]

Just to let you know, internally at Everything Solved we have basically-complete patches which do this for 3.0, and which we have permission to release.

They address LpSolit's concern #1, but not #2 which is unavoidable.

Comment 14

[Teemu Mannermaa (:wicked)]

Comment on attachment 250935 [details] [diff] [review]
patch for tip

This doesn't apply cleanly anymore so let's take better patch from mkanat instead.

Comment 15

[Vitaly Fedrushkov]

See also bug 407752

Comment 17

[Omar Ali]

Attachment: v1

I attached a patch for adding the term product to variables.none.tmpl. I ran the tests and confirmed that there were no regressions. I'm adding the patch here because the bug that I opened (1152518) was marked as duplicate of this bug.

Comment 18

[Omar Ali]

Attachment: v1.1

Updating diff to fix one instance of the term product that I missed in user-error.html.tmpl

Comment 19

[:glob ✱]

sorry to do this to you omar, but i think this bug should not be fixed.

it adds a lot more complexity to the product, especially during development, and imho doesn't provide enough of a gain to offset that complexity.

it doesn't make sense to just do product without component, so the amount of changes you see in omar's patch is only part of the impact.


justdave, mcote: what are your thoughts on this?

Comment 20

[Omar Ali]

Attachment: v2, patch for product and component

For completeness, and for the benefit of other bugzilla users, I updated the patch to also include component. It wasn't that difficult since component is mentioned fewer times than product.

I don't think this add too much complexity. We are already doing the same thing for the terms 'bug' and 'comment'.

Comment 21

[Marc Schumann [:Wurblzap]]

Maybe this should block bug 218746?

Comment 22

[Frédéric Buclin]

(In reply to Omar Ali from comment #20)
> I don't think this add too much complexity. We are already doing the same
> thing for the terms 'bug' and 'comment'.

It definitely adds complexity, especially when you think about all these /[a|A|][p|P]roduct/ combinations. We don't do it for comment(s); the reason they appear in variables.none.tmpl is for quoteUrls() only, but they are not used in templates. And for "bug", this is a whole separate story. It's very common to read "issue" or "ticket" instead of "bug".

I agree with glob that we shouldn't do this. Bugzilla has classifications, products and components. If you want to rename them to category, sub-category, and sub-sub-category, well, maybe this could make sense, but does it worth the complexity involved? And then one will probably want to rename "severity" and then "priority", etc... [% terms.Things %] [%+ terms.would %] [%+ terms.become %] [%+ terms.much %] [%+ terms.less %] [%+ terms.readable %].

Comment 23

[Marc Schumann [:Wurblzap]]

My 2c is that, for these two terms, it is indeed worth the complexity. The terms "product" and "component" are so specific that they match a very narrow spectrum of Bugzilla use cases only. If we had a more generic term (think "classification" -- we're hearing few complaints about this), it wouldn't be much of a problem, but "product" and "component" don't work very well as generic terms.

Comment 24

[Mark Côté [:mcote]]

I don't think I'm the appropriate person to make a call here, but I do see Marc and Omar's point.  "Product" and "Component" are a lot more arbitrary than many other fields, as Myk pointed out in comment 4, so I see an argument for making Product and Component configurable but stopping there.

However, I can't really comment on the added complexity.  If glob thinks it significantly increases complexity and development/maintenance burden, I would go with his recommendation.

Comment 25

[:glob ✱]

marking as wontfix.

(In reply to Omar Ali from comment #20)
> Created attachment 8591287 [details] [diff] [review]
> v2, patch for product and component
> I don't think this add too much complexity.

even with this patch the API, DTD, and documentation will still refer to 'products' and 'components'.

Comment 26

[Marc Schumann [:Wurblzap]]

This is circular reasoning. You're stating (a part of) the problem as a reason not to fix it.

Comment 27

[Omar Ali]

> even with this patch the API, DTD, and documentation will still refer to
> 'products' and 'components'.

Isn't this also true for the other terms in variables.none.tmpl? Does the API, DTD, and documentation currently use the custom terms for 'Bug', 'Comment' and 'Bugzilla'?

Comment 28

[Andre Klapper]

glob: Could you please reply to the last two comments (that I also sympathize with)?

Comment 29

[Andre Klapper]

glob: Could you please reply to the last two comments (that I also sympathize with)?

Comment 30

[:glob ✱]

the crux of this is this adds a real cost to ongoing maintenance that we cannot afford.
yes, there are inconsistencies with the current 'terms' implementation, but that's a side point.