Closed Bug 13540 Opened 21 years ago Closed 17 years ago
Bugzilla should be more generic, adaptable, and customizable
Hello Terry, I have been toying with Bugzilla 2.6 recently. I have come to the conclusion that Bugzilla serves well not JUST as a bug reporting system, bug as a general solution for the more general idea of "problem" or "incident" reporting. In fact, I've found this out as I continue trying to hack Bugzilla for use as a contact management system for an association management provider firm that I am currently working for. This being the case, I have been changing the term "bug" in many cases to "report." I'd like to suggest that Bugzilla use this term in appropriate cases in the stock code distribution as well.
CC'ing someone who might be interested.
I'm actually designing a problem reporting system at the moment, with different sort of goals to Bugzilla, and I generally use the terminology "problem report".
I use the term "report," because in my case, they are "contact reports" that I am dealing with. Not even necessarily "problems" at all. That's why I'm saying I think Bugzilla is great for tracking ANY kind of thing that needs attention, be it a problem, or just something that plain needs attention. I'm saying I think Bugzilla can be adapted to suit a much more general set of conditions with these kinds of needs. Bugzilla is VERY adaptable, and very flexible. I'm saying I think the terminology should reflect this flexibility a little.
I've been thinking that it would be good if Bugzilla was "modular". For example, you could have a dependencies module, a milestones module, etc. They would allow you to plug in your own bits, and remove what you don't want. This could be related to that.
Severity: normal → enhancement
Summary: Usage of "bug" would serve better as "report" in many cases → Bugzilla should be more generic, adaptable, and customizable
I think your ideas there are *VERY* much related to my idea. In fact, I think you've hit upon the larger issue I'm heading towards (without even realizing it). So, I'm changing the bug summary to reflect this. I think the idea for modularity, (greater) customizability, extensibility, etc., is a general idea which is well worth looking into. IMHO, this would make Bugzilla much easier to customize/adapt to people's own projects/needs. Actually, looking at the code here, I think the main thing that needs to be done to achieve this is to do some cleanup/reorganization of the code. I think Bugzilla is conceptually a VERY sound (and complete) design, but the code is a little bit ugly, and quite Mozilla-specific. The latter does not surprise me, since Bugzilla (I assume) was originally designed to address a very specific need that Mozilla had. However, I do think that since Bugzilla is also becoming a noteworthy product in itself now, this idea is worth considering. Terry, is the Bugzilla code in CVS exactly what Mozilla.org uses for its particular installation at this given moment? I guess the reason I'm asking is that I'd like to know if it is okay for me to check stuff in (pending review by you, if you desire) to this tree, or if I would potentially be messing up the code that Mozilla.org is using in its installation.
Yep, I've been meaning to submit something about this. Here's what I think a module should have. (1) A set of fields that it maps to on the underlying database. There needs to be some way of adding/removing modules and hence fields and knowing how this would map to the database underneath (SQL actions?). (2) A set of module that this is dependant on and can hence be relied on to be present. (3) Both a simple legal field values specifications, and possibly inter-field constraints as well. (4) Triggers on change, eg for dependencies.
It's hard to disagree with much of anything written here, since it's all wrapped up in motherhood and apple pie. But it's real work to do all this and to do it well, and I'm not likely to have the cycles. I will happily look at any patches, and will take things that look good and don't irrevokably break any existing installations. The http://bugzilla.mozilla.org/ installation of bugzilla *does* run off of the tip. This is a little too aggressive, I agree, but I will always want it to be running very near the tip. So, no, I do not want things checked into the tree directly, until I have reviewed a patch and given it an OK. If you prefer, we can also set up a branch on the tree for stuff. (Just don't go living on the branch too long; when a branch and the tip diverge for very long, it becomes very very hard to land the branch. This is why the Redhat changes never made it into Bugzilla.) If you really plan on working on making bugzilla more "generic, adaptable, and customizable", feel free to reassign this bug to yourself.
Re-assigning to myself then. I probably won't have too much time to work on it at the moment, so don't expect anything anytime soon, but I will try to work on it as I find the time.
Accepting new assignment.
Summary: Bugzilla should be more generic, adaptable, and customizable → [HELP WANTED] Bugzilla should be more generic, adaptable, and customizable
Would love it if anyone wants to help achieve this goal.
Well, I can talk, but am unlikely to be able to code anything. One thing you'll have to be wary of is what to do with the query and bug screens. - Where do you place the fields in comparison to the others? - What widgets do they use? - Is there some way to group related fields that might be in totally different modules?
After seeing the Redhat Bugzilla site ( http://developer.redhat.com/bugzilla/ ), I'm not sure how extendible Bugzilla is. Have they just hacked everything out, or is this modularity partly there, and if so, what? This might be obvious, but the way I would suggest to do this is implement the module system and then attempt to add new modules. Then you could try to move the base functionality into modules.
Redhat hacked the hell out of Bugzilla a long time ago, promised to land their changes, and never did. The longer they put off landing, the harder it is to land it, and so the less likely it is to happen. This is a sore point with me. And, yeah, of course things can always be designed to make such things easier. As I said above, this is all real work.
I just submitted bug #5953 to Red Hat's Bugzilla. You can see it at http://developer.redhat.com/bugzilla/show_bug.cgi?id=5953
Repeat for me what the other Matty T said ... I can brainstorm good ideas whenever you need them, but learning C++ will have to wait a while.
Another idea has occured to me... Terry, tell me how feasable you think this is, but how about creating a sort of INI type thingy for Bugzilla, or perhaps several INI files, where one could store certain settings, like the name of the project (Mozilla in Mozilla's case, or "Red Hat" in Red Hat's case, etc.), the bug resolutions (AbiSource uses different ones from Mozilla, for example), and (dare I say this--this one will probably explode into another holy war) query screen settings? This would definitely help to make Bugzilla more adaptable, since people then wouldn't have to tinker with the code itself so much to change these things. What do you think?
Since the development roadmap basically is echoing what I wrote in this bug so long ago, I am re-assigning it to someone who might be able to help. Perhaps we could use this as a meta-bug, to track more specific things that can be done to achieve the goal stated in this one?
Assignee: zuperdee → tara
Status: ASSIGNED → NEW
Summary: [HELP WANTED] Bugzilla should be more generic, adaptable, and customizable → Bugzilla should be more generic, adaptable, and customizable
An idea for implementation... There could be a "modules" directory. Inside this directory would either be a directory for each module with a set of files in it. The reason it needs to be more than one file for each module is there needs to be at least one routine that doesn't have any dependencies on CGI.pl or globals.pl that can be called by checksetup.pl to assure that any database or setup requirements of that module are in place. Things like whiteboard status, URLs, and keywords would be really good candidates to get modules, since they're already in places within the query screen which make them easy to add/remove at will (and a couple of those already can be via params). The next question is how to deal with module management. Since checksetup needs to be able to know which ones you're using, one of three things would need to be done... Either 1) a list of modules to be used should be placed in localconfig, 2) two directories should exist, one for modules in use, and one for modules not in use, or 3) a flag file of some sort should be placed in the module directory to tell if it's in use or not. Personally, of those 3, I think #3 would most lend itself to being able to manage which modules are in use from the web interface. Things each module would need to have: 1) as mentioned above, a setup file that can be called by checksetup to ensure any database or other setup dependencies are met. 2) a way to define fields for the enter_bug, query, and show_bug screens. perhaps with some sort of "field type" definition that will allow the above cgi's to make intelligent decisions about where to place the fields on the generated pages. 3) routines that can be called if any of the defined fields exist in a submitted form that will add the necessary SQL to the database query, or update the necessary information in the database, as required. 4) a way to define columns that can be shown on the buglist.cgi page. Wow, this sounds like a huge project now. But definitely something that could be done, if someone had a few days to sit down and spend on it. I would think a good definition of how the modules will interact with bugzilla would be important to have before any programming work starts on it, to ensure future expansion capabilities of the modules after they've been created.
Dave--this is exactly the sort of thing Chris and I have been kicking around, and it ties into the whole change in concept on how parameters are handled that we've also been kicking around. At some point in the next week or so we're probably going to sit down with some folks who know a lot more about database structures than we do and stare really hard at the current schema, see where we need to go, then start working from that point on the rest of the project would change around it.
Status: NEW → ASSIGNED
The more I've thought about this the more I think that you're going to have to have a lot of hooks. And there's probably going to be a lot of cruft and various other things in Bugzilla not designed with this in mind. But whoever does this will have the adoration of people worldwide. Bring on the draft spec!
*** Bug 58924 has been marked as a duplicate of this bug. ***
This should be an easy fix, taking...
Assignee: tara → ian
Status: ASSIGNED → NEW
Adding default QA contact to all open Webtools/Bugzilla bugs lacking one. Sorry for the spam.
QA Contact: matty
Moving to real milestones...
Target Milestone: --- → Bugzilla 3.0
Taking all Bugzilla 3.0 bugs -- congratulations to MattyT for the triage, it really was spot on. Note: I may end up pushing some of these bugs back to 3.2, we'll see. However, I believe all these bugs should just fall out of the redesign. Let's hope I'm right! (Note: I'm also resetting the priority field to "---" so that I can retriage any that I consider important or likely to be dropped.)
Component: Bugzilla → Bugzilla 3
Priority: P3 → --
The Bugzilla 3 component is going away. We're going to depend on the Milestones for this. At the time this component was created, we didn't have milestones for Bugzilla.
Component: Bugzilla 3 → Bugzilla
Component: Bugzilla → Bugzilla-General
Priority: -- → P2
Product: Webtools → Bugzilla
Version: other → unspecified
We recently adopted Bugzilla (woohoo for the good guys!) for tracking things in our shop. One of our big selling points was that we had the source code, so could adapt it. In our case, Management didn't like the term "bug", so I went through and changed all visible cases of "bug" with "issue" (including in autolinkification). The ability to change some of the visual aspects of the program would be good as a global thing (like "$callBugs ='bug';" and "$noBugsFoundmsg ='Zaroo Boogs found';" in globals.pl)... I'll gladly help with this idea as soon as the trunk gets back to letting Windows work, till then I'm stuck back at 2.14.4 (I couldnt convince them to let me run it on a linux box :-(
I have suffered through the same changes of renaming "bug" to "issue" (as well as rebranding Bugzilla to another name) in my installation and would be willing to submit a patch for 2.17.3 in an effort to ease the pain of upgrading. My solution was to introduce a new template (../global/variable.html.tmpl) that defined "bug.label" and "app.name" and simply added a [% INCLUDE global/variables.html.tmpl %] statement to all pages that had a reference to. This works for everything that is templatized however there are still a few cgi scripts (i.e. reports.cgi) that create html and have "bug" in there that require a hard coded replacement. My thought was if this were added to the Parameters page it could be referenced in both cgi and templates. If this is the preferred location please let me know. I'd like to have this incorporated in the 2.18 release.
I'm all for it. Eventually everything output to a user will be a template so that's definitely the right place to put it for the long term. Big thing to keep in mind is there's a variety of ways the word might be used (initial caps or not, plural or not, etc).
I went through all the 2.17.3 templates and replaced hard coded references to bug (all cases), the "zero issues found" and Bugzilla replacing them with variables defined in a new template global/variables.none.tmpl. Any chance this can make the 2.17.5 release?
Previous zip file contained customized values for termanology for my testing purposes. This zip file contains existing hard-coded values for "bugLabel", "appName", "permissionBit", "zeroSearchResults" and the singular/plural modifiers.
Attachment #121734 - Attachment is obsolete: true
I don't think this issue really blocks 48822 (a XUL interface to Bugzilla), which has just been resolved fixed without this bug being fixed, so removing that bug from this bug's blocker list.
No longer blocks: 48822
Comment on attachment 121738 [details] 2.17.3 based patch using termanology variables across all templates Requesting review of the submitted patch as I'd like to have this incorporated in the next release.
Attachment #121738 - Flags: review?
Comment on attachment 121738 [details] 2.17.3 based patch using termanology variables across all templates You should ask someone specific to review the patch or else it'll never happen. Making that person be me for the moment, but I'm overworked, so if you don't get a response quickly enough feel free to move the request to someone else.
Attachment #121738 - Flags: review? → review?(myk)
Jon, The customary way to attach a patch is to perform a unified diff and attach the result. This makes it very easy for a reviewer to see exactly what you changed and they can also apply it to a version that is not exactly what you started with. Please attach your patch as a unified diff. If you need help with this, the IRC channel is a good place for tricks.
The attached path (in unified diff format) replaces hard-coded BZ termanology (i.e. all instances of the word bug, in all cases and plural/singular) with variables defined in template/en/default/global/variables.none.tmpl. I couldn't get the new template included in the diff, so I'll attach that separately.
Comment on attachment 125851 [details] [diff] [review] 2.17.4 based patch to replace hardcoded termanology with template variables Requesting review of patch for inclusion in next maintenance release.
My thoughts: - We are eliminating use of "|" in favour of "FILTER", because it's much easier for our auto-security-hole-detection scripts to spot. - "global.terms" seems overkill - "terms" would do fine. - +[% INCLUDE global/variables.none.tmpl %] could this be done in header.html.tmpl? If it's needed beforehand in a couple of templates, we could include it twice. - global.terms.pluralBugLabelModifier is very long-winded :-) I don't know if TT supports case-sensitive hash keys, but if I does, I suggest: terms.bug terms.bugs terms.Bug terms.Bugs This avoids upper/lowercase and plural/singular issues in a simple, easy to understand, short way. - Also, this brings out a more general point. We should be using e.g. terms.Bugzilla instead of terms.appName - this makes the page read much more sanely. - Please keep lines to < 80 chars where possible. Gerv
Replaced variables with case sensitive versions. Also renamed global.terms.appName with global.terms.Bugzilla.
Attachment #125852 - Attachment is obsolete: true
This revision replaces the "FILTER" shorthand "|" with the longer version to support auto-security-hole-detection scripts. So many of the 112 templates use "Bug" in the "title" variable passed to the header.html.tmpl that I decided for consistency to be explicite in the reference. "global" is a namespace declaration that allows variables to be used from included files and as such has to remain. TT does support case-sensitive hash keys, so I've replaced the per template concatination with appropriate case-sensitive variables in variables.none.tmpl. I've also replaced global.terms.appName with global.terms.Bugzilla.
Attachment #125851 - Attachment is obsolete: true
> This revision replaces the "FILTER" shorthand "|" with the longer version to > support auto-security-hole-detection scripts. You are, of course, running this script (along with the other tests) and making sure Bugzilla still passes with your patch applied, aren't you? ;-) (runtests.sh) > "global" is a namespace > declaration that allows variables to be used from included files and as such > has to remain. I don't understand this sentence. There is no technical reason why you need the "global". I had another idea, actually. You could save all the "FILTER html"s by either: - specifying that terms are plaintext only (a reasonable restriction IMO) or - having a variables.html.tmpl file which is included in the HTML files, and a variables.csv.tmpl for CSV, etc, and a variables.none.tmpl for other things. Out of curiousity, why have you used this mechanism for the words "bit" and "bits"? Gerv
I was not aware of the runtest.pl script and did manual click-through testing to ensure everything worked. Unfortunately, I am not able to run the runtest.pl script as returned what I believe to be perl environment config errors: bash-2.03$ /usr/bonsaitools/bin/perl runtests.pl t/001compile........Can't locate Test/More.pm in @INC (@INC contains: t /opt/per l/lib/5.6.1/sun4-solaris-thread- multi /opt/perl/lib/5.6.1 /opt/perl/lib/site_perl/5.6.1/sun4-solaris-thread- multi /opt/perl/lib/site_perl/5.6.1 /opt/perl/lib/site_perl .) at t/001compile.t line 33. BEGIN failed--compilation aborted at t/001compile.t line 33. t/001compile........dubious Test returned status 2 (wstat 512, 0x200) t/002goodperl.......Can't locate Test/More.pm in @INC (@INC contains: t /opt/perl/lib/5.6.1/sun4-solaris-thread- multi /opt/perl/lib/5.6.1 /opt/perl/lib/site_perl/5.6.1/sun4-solaris-thread- multi /opt/perl/lib/site_perl/5.6.1 /opt/perl/lib/site_perl .) at t/002goodperl.t line 35. BEGIN failed--compilation aborted at t/002goodperl.t line 35. t/002goodperl.......dubious Test returned status 2 (wstat 512, 0x200) t/003safesys........Can't locate Test/More.pm in @INC (@INC contains: t /opt/perl/lib/5.6.1/sun4-solaris-thread- multi /opt/perl/lib/5.6.1 /opt/perl/lib/site_perl/5.6.1/sun4-solaris-thread- multi /opt/perl/lib/site_perl/5.6.1 /opt/perl/lib/site_perl .) at t/003safesys.t line 33. BEGIN failed--compilation aborted at t/003safesys.t line 33. t/003safesys........dubious Test returned status 2 (wstat 512, 0x200) t/004template.......Can't locate Test/More.pm in @INC (@INC contains: t /opt/perl/lib/5.6.1/sun4-solaris-thread- multi /opt/perl/lib/5.6.1 /opt/perl/lib/site_perl/5.6.1/sun4-solaris-thread- multi /opt/perl/lib/site_perl/5.6.1 /opt/perl/lib/site_perl .) at t/004template.t line 41. BEGIN failed--compilation aborted at t/004template.t line 41. t/004template.......dubious Test returned status 2 (wstat 512, 0x200) t/005no_tabs........Can't locate Test/More.pm in @INC (@INC contains: t /opt/perl/lib/5.6.1/sun4-solaris-thread- multi /opt/perl/lib/5.6.1 /opt/perl/lib/site_perl/5.6.1/sun4-solaris-thread- multi /opt/perl/lib/site_perl/5.6.1 /opt/perl/lib/site_perl .) at t/005no_tabs.t line 36. BEGIN failed--compilation aborted at t/005no_tabs.t line 37. t/005no_tabs........dubious Test returned status 2 (wstat 512, 0x200) t/006spellcheck.....Can't locate Test/More.pm in @INC (@INC contains: t /opt/perl/lib/5.6.1/sun4-solaris-thread- multi /opt/perl/lib/5.6.1 /opt/perl/lib/site_perl/5.6.1/sun4-solaris-thread- multi /opt/perl/lib/site_perl/5.6.1 /opt/perl/lib/site_perl .) at t/006spellcheck.t line 43. BEGIN failed--compilation aborted at t/006spellcheck.t line 43. t/006spellcheck.....dubious Test returned status 2 (wstat 512, 0x200) t/007util...........Can't locate Test/More.pm in @INC (@INC contains: t /opt/perl/lib/5.6.1/sun4-solaris-thread- multi /opt/perl/lib/5.6.1 /opt/perl/lib/site_perl/5.6.1/sun4-solaris-thread- multi /opt/perl/lib/site_perl/5.6.1 /opt/perl/lib/site_perl .) at t/007util.t line 31. BEGIN failed--compilation aborted at t/007util.t line 31. t/007util...........dubious Test returned status 2 (wstat 512, 0x200) t/008filter.........Can't locate Test/More.pm in @INC (@INC contains: t /opt/perl/lib/5.6.1/sun4-solaris-thread- multi /opt/perl/lib/5.6.1 /opt/perl/lib/site_perl/5.6.1/sun4-solaris-thread- multi /opt/perl/lib/site_perl/5.6.1 /opt/perl/lib/site_perl .) at t/008filter.t line 39. BEGIN failed--compilation aborted at t/008filter.t line 39. t/008filter.........dubious Test returned status 2 (wstat 512, 0x200) Uncaught exception from user code: FAILED--8 test scripts could be run, alas--no output ever seen Test::Harness::runtests ('t/001compile.t', 't/002goodperl.t', 't/003safes ys.t', 't/004template.t', 't/005no_tabs.t', 't/006spellcheck.t', 't/007util.t', 't/008filter.t') called at runtests.pl line 41 bash-2.03$ There actually is a very good technical reason to include global...TT requires it ;). http://www.template- toolkit.org/docs/plain/Manual/Variables.html#Local_and_Global_Variables I like the idea of having variables.html.tmpl, variables.csv.tmpl, but also think the plain text restriction is reasonable and simplifies things tremendously. I'm willing to do either to get this incorporated in the next release.
> bash-2.03$ /usr/bonsaitools/bin/perl runtests.pl > t/001compile........Can't locate Test/More.pm in @INC (@INC contains: You need to install the Test framework :-) I believe perl -MCPAN -e "install 'Test'" should do the trick, but I'm not sure. > There actually is a very good technical reason to include global...TT requires > it ;). But if something is included at the top level, it'll be visible to all sub-templates anyway. If it does turn out we need it, then you could do: [% terms = global.terms %] in the variables.x.tmpl template, so everyone could use the shorter syntax. (The global keyword does not persist values between requests - you knew that, right?) > I like the idea of having variables.html.tmpl, variables.csv.tmpl, but also > think the plain text restriction is reasonable and simplifies things > tremendously. Let's go with the plain text restriction then, call it variables.none.tmpl, and add an exception to 008template.t to exclude all directives starting with "terms." Gerv
Incorporated Gerv's requests for shorter variable names.
Shorter variable names per Gerv's request.
Attachment #126042 - Attachment is obsolete: true
Comment on attachment 126564 [details] [diff] [review] 2.17.4 based patch to replace hardcoded termanology with template variables (Version 3) Pants. One mis-click and there goes a whole review. Basically, r=gerv if you fix: - The unnecessary filter in index.html.tmpl (line 10 or so of the patch) - The few instances where you are still using the typeFooBarBaz style of type declaration - search carefully, I think there are at least 3 - the places where you do BLOCK%] instead of BLOCK %] (that's a nit.) Gerv
Removed the unnecessary filter in index.html.tmpl Replaced | html with "FILTER html" \template\en\default\global\hidden-fields.html.tmpl Left "typeLabelLowerPlural" & "typeLabelLowerSingular" variables in \template\en\default\admin\flag-type\edit.html.tmpl as the value is either terms.bug or attachment depending on the flag type. terms.zeroSearchResults remains
Attachment #126564 - Attachment is obsolete: true
Comment on attachment 126628 [details] [diff] [review] 2.17.4 based patch to replace hardcoded termanology with template variables (Version 4) r=gerv. John - you don't have checkin privs, do you? Gerv
Attachment #126628 - Flags: review+
-> patch author The patch is huge, so flagging the huge patches bug as a dependency so the people who care get notified that it's coming down the pike.
Assignee: ian → jwilmoth
Flags: approval? → approval+
Target Milestone: Bugzilla 3.0 → Bugzilla 2.18
This version combines the two patches, removes all the Windows line endings and tabs, merges it to the tip and fixes all the conflicts, and makes all the tests pass. Phew :-) Gerv
I plan to check this in pretty soon - firstname.lastname@example.org, if you have a second, could you look it over and make sure I haven't broken anything you can see? Thanks, Gerv
Fixed. (I won't list all the checkin logs here.) Thanks to Jon for persevering with this. Gerv
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
Nobody ran tests.... the tree is burning... http://tinderbox.mozilla.org/showbuilds.cgi?tree=Bugzilla
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
That's really weird. I ran tests before checking in, and they all passed - and the errors it's flagging correspond to errors I know I fixed during the merge. <checks> It seems filterexceptions.pl didn't get checked in. <sigh> Gerv
Status: REOPENED → RESOLVED
Closed: 17 years ago → 17 years ago
Resolution: --- → FIXED
Comment on attachment 121738 [details] 2.17.3 based patch using termanology variables across all templates cancelling unneeded review request
Attachment #121738 - Flags: review?(myk)
Comment on attachment 125851 [details] [diff] [review] 2.17.4 based patch to replace hardcoded termanology with template variables cancelling unneeded review request
*** Bug 48101 has been marked as a duplicate of this bug. ***
There are similar changes /updates we would like to see in bugzilla. I would like to know if the changes have been completed and whether we could avail the same if were to install bugzilla now. Please read the BUG #344086 asking for same customization changes
(In reply to comment #42) > Out of curiousity, why have you used this mechanism for the words "bit" and "bits"? That's a very good question. This term is unusable for translation, and is only used in 3-4 places.
So...how do I change my bugzilla (3.4.1) to say "issues" instead of "bugs"?
You need to log in before you can comment on or make changes to this bug.