Closed Bug 26940 Opened 20 years ago Closed 6 years ago

Restrict Keywords to certain products/components.


(Bugzilla :: Creating/Changing Bugs, enhancement, P4)






(Reporter: CodeMachine, Unassigned)



It would be nice if keywords could be defined to have restrictions.  Examples
could be along the lines of:

beta1 : milestone < m15
css1 : component = Style System

This could help ensure keywords are used properly and are removed when they no
longer apply.

If a keyword is added and the restriction fails, the change should be refused
and the changer should go back and fix it.

If changes made break a restriction where a keyword already present, the change
should again be refused.

If changes made result in a restriction that didn't previously hold still not
holding, a warning should be issued on the process bug screen.  This is for
legacy/transitional purposes since the person making the change might not be the
one in a position to fix the restrictions.  There could also be some whining
emails sent by a periodic agent that checks for these as well.

I don't particularly care about the interface for defining the restrictions, but
if there was a web capability, the query screen selection could be used.
Restrictions could apply to dependents, dependees or the current bug.  For
example, if there was a PDT+ keyword, you'd want it restricted to when all the
bugs it depends on are also PDT+.

This could partially help the situation where people shift things out which
people are blocked on without realising it. is the new owner of Bugzilla and Bonsai.  (For details,
see my posting in netscape.public.mozilla.webtools,
news:// .)
Assignee: terry → tara
I think this is becoming increasingly important as the number of keywords in  People are becomingly increasingly reluctant to add
keywords.  I believe the primary reason is that it's hard to learn them all.

If we had this we could separate them out:

Component = Style System


Milestone <= M15


the ones that are currently applicable to this bug report would appear at the
top, and the ones with the same restrictions would be grouped, making it easier
to see which are applicable!
3.0:  This should at least be considered from a schema POV.
QA Contact: matty
Whiteboard: 3.0
beta1 should apply regardless of the target milestone, since it is a nomination
keyword, and any bug can be nominated, whatever the current target.

css1 should apply regardless of the component, in fact many CSS bugs are Layout
bugs and not Style System bugs.
beta1 => beta1+

component => product
Moving to real milestones...
Whiteboard: 3.0
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.)
Assignee: tara → ian
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 
Component: Bugzilla 3 → Bugzilla
Component: Bugzilla → Bugzilla-General
Product: Webtools → Bugzilla
Version: other → unspecified
would love to see this for use in Tech Evang as we are using lots of stuff in
the status whiteboard that we would love to use keywords for.
Taking this back to 2.18. This shouldn't be too hard to code and will make 
tech evangelism work much easier. To start off, this could be configured 
by a text configuration file or something in localconfig that would look like:

keyword -> condition

condition could contain one of the following magic strings which would 
apply to a bug:

(other things could be added here, this is just a rough braindump)

attributes like >, <, =~, eq, or ne would be follow the magic string var. 

Whenever a bug is changed, any conditions attached are examined to 
see if they are still met and if not an error is raised. 

There is lots of potential for this, but taking it a step further, one could 
attach conditions to individual bugs. For example, a meta bug of release 
blockers could be setup that only asa and add dependancies to. The 
condition could be written like:

changer ne '' && action eq 'adddep'

While this would take some work to impliment, I am willing to help with 
this. The first thing to do would be to write a module to parse and evaluate 
the conditions. Once that is done, all that has to be done is hooking it up 
to a UI. 
Assignee: ian → myk
Component: Bugzilla-General → Creating/Changing Bugs
Target Milestone: Bugzilla 3.0 → Bugzilla 2.18
Enhancements which don't currently have patches on them which are targetted at
2.18 are being retargetted to 2.20 because we're about to freeze for 2.18. 
Consideration will be taken for moving items back to 2.18 on a case-by-case
basis (but is unlikely for enhancements)
Target Milestone: Bugzilla 2.18 → Bugzilla 2.20
Bugzilla 2.20 feature set is now frozen as of 15 Sept 2004.  Anything flagged
enhancement that hasn't already landed is being pushed out.  If this bug is
otherwise ready to land, we'll handle it on a case-by-case basis, please set the
blocking2.20 flag to '?' if you think it qualifies.
Target Milestone: Bugzilla 2.20 → Bugzilla 2.22
Assignee: myk → create-and-change
QA Contact: mattyt-bugzilla → default-qa
Target Milestone: Bugzilla 2.22 → ---
This would be handled by a combination of bug 287330 and bug 308253.
Depends on: 287330, 308253
Priority: -- → P4
Summary: Keyword restrictions. → Restrict Keywords to certain products/components.
The two dependent bugs have since been fixed.
Closed: 6 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.