Parameter for "default blocked bug" to be used in post_bug.cgi

NEW
Unassigned

Status

()

Bugzilla
Creating/Changing Bugs
13 years ago
8 years ago

People

(Reporter: Christian Reis, Unassigned)

Tracking

Details

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

13 years ago
Some sites tie *all* bugs via blockers, which means that there is always a graph
that can be followed from a main bug to children. This makes it a lot easier to
control bugs because the dependency tree can be used to keep tabs on the whole
set of bugs open instead of having us rely on a large set of queries.

This is, apparently, how MS Project keeps tabs on all tasks, btw. :-)
Created attachment 154406 [details] [diff] [review]
include the default blocker bug option in parameters

when the new parameter defaultblockerbug is set, the field depends on will be
seted to this value when creating new bugs.
Attachment #154406 - Flags: review?(kiko)

Comment 2

13 years ago
Kiko,

A few things to think about...

  Do you want to limit this to just the default blocker or should it be any of
the fields that can be set by a bookmarkable template?

  Should this be global or per-product??

(Reporter)

Comment 3

13 years ago
Hmmm. Both are good questions. I hadn't realized you can poison enter_bug's GET
to include a default dependson, which renders this silly, unless it *is*
per-product. 

Note that there is also a need to *require* a bug to be on a blocked list which
is somewhat related to the problem here but implementation-orthogonal. 
Assignee: kiko → michetti
(Reporter)

Comment 4

13 years ago
Comment on attachment 154406 [details] [diff] [review]
include the default blocker bug option in parameters

>Index: defparams.pl
>+sub check_defblocker {
>+  my ($bugid) = @_;
>+
>+  if ($bugid =~ /\D/g){
>+   return "Bug number must be a positive integer";
>+  } 
>+  
>+  my $sql_bug = trim(&::SqlQuote($bugid));
>+
>+  &::SendSQL("SELECT bug_id FROM bugs WHERE bug_id = $sql_bug");
>+  if (!(&::FetchOneColumn()) && $bugid ne ''){
>+    return "Bug $bugid not found.";
>+  }
>+
>+  return "";
>+}

Isn't this more easily accomplished by doing something like 

  my $bug = new Bugzilla::Bug($bugid);
  if (!$bug) {
    # error
  }

>+  {
>+   name    => 'defaultblockerbug',
>+   desc    => 'Set the number of a bug that all new bugs will depends on',

Hmmm. I think I got the naming wrong :-) Oops. Basically, it's a bug that by
default *is blocked by* the new bug. IOW, when you create a new bug, the new
bug should block the bug specified here. I'll update the summary.
Attachment #154406 - Flags: review?(kiko) → review-
(Reporter)

Updated

13 years ago
Status: NEW → ASSIGNED
Summary: Parameter for "default blocker" to be used in post_bug.cgi → Parameter for "default blocked bug" to be used in post_bug.cgi
Created attachment 154776 [details] [diff] [review]
parameter to set a default parent for new bugs

changes in defparams.pl and /bug/create/create.html.tmpl
Attachment #154406 - Attachment is obsolete: true
Attachment #154776 - Flags: review?(kiko)

Comment 6

13 years ago
Doing this means that anybody creating a bug using the bookmarkable template
will be unable to speciy a blocked bug in the template.  Should we just append
the default blocked bug to whatever is in the blocked variable?

Comment 7

13 years ago

Actually, we should take the one step further...

Today, if I use this...
http://bugzilla.mozilla.org/enter_bug.cgi?product=Bugzilla&blocked=252335
I will go straight to entering a bug that blocks this one.

The problem is, if I use...
http://bugzilla.mozilla.org/enter_bug.cgi?blocked=252335

The first page I hit asks me to select a product and the "blocked=252335" does
not even propagate through to the URLs for each product.

Ideally, we could fulfil the needs of this bug by permitting a default bug
template to be applied to the entire system or to a specific product.  This has
the added advantage of making it possible to provide a default CC list (an
often-requested feature) or providing a boilerplate template in the description
section.

Naturally, we would have to make the interface usable by people who don't want
to hack URLs.

What do you think?
(Reporter)

Comment 8

13 years ago
Hmmm. So you're saying a per-product template of default values? It's not a bad
idea.. certainly cleaner than adding a new Param for this.

Comment 9

13 years ago
Yes.  That's what I am thinking about.  The part that I have not yet worked out
in my own mind is how you handle the situation where the user has their own
bookmarked template.  Do we try to combine them or do we let one win over the other?
Bookmarked template is equivalent to passing in URL parameters, and the template
and/or passed params should *always* win.

I will absolutely veto any attempt at a param to set a default blocker.  That
just smells like an edge case that should remain as someone's local hack.  The
idea of a per-product default template sounds quite intriguing and usable to me
however.  We'd likely make use of it on b.m.o to override the OS/platform values
for the webtools products, for example :)

Comment 11

13 years ago
Here is what I am thinking of....

1) Each product gets a default-template field.  In that, we store the equivalent
of a bookmarked template.

2) In editproducts, we add a function, usable by people with appropriate
permissions (distinct from full editcomponents or tweakparms)  to permit us to
update the defaukt-template.

3) When we ask to update the default template, we reuse the same TT-template
used to create a bug and prepopulate it with any values from the current
default-template.  It's knob is changed to a "Save" button.

4) When a user creates a bug in that product, the template values should be
loaded if specified and OR'd with any values from a user's bookmarked template.
[[Question -- what to do in case of conflict?? ]]

You need editbugs to give dependencies while entering a new bug. Is this an 
issue?
(Reporter)

Comment 13

13 years ago
The funny thing about midairs. I just tried to add a comment that said:

How do you see this template being implemented? Like a set of form values
(perhaps using the post_bug template itself) that would be stored attached to a
product? Or to a component?

Funny how Joel and I seem to have hit it identically.
(Reporter)

Comment 14

13 years ago
(In reply to comment #11)
> 4) When a user creates a bug in that product, the template values should be
> loaded if specified and OR'd with any values from a user's bookmarked template.
> [[Question -- what to do in case of conflict?? ]]

I think the template values should be a default -- any parameters supplied via
GET /POST in that specific request should override them. Isn't that what Dave
suggested in comment 10?

Comment 15

13 years ago
Comment on attachment 154776 [details] [diff] [review]
parameter to set a default parent for new bugs

justdave vetoed the idea implemented in this patch in bug 10.
Attachment #154776 - Flags: review?(kiko) → review-

Updated

12 years ago
QA Contact: mattyt-bugzilla → default-qa

Updated

8 years ago
Assignee: michetti → create-and-change
Status: ASSIGNED → NEW
You need to log in before you can comment on or make changes to this bug.