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

Status: NEW

(Bugzilla :: Creating/Changing Bugs, defect)

Description

[Christian Reis]

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. :-)

Comment 1

[Alexandre Michetti Manduca]

Attachment: 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.

Comment 2

[Joel Peshkin]

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??

Comment 3

[Christian Reis]

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. 

Comment 4

[Christian Reis]

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.

Comment 5

[Alexandre Michetti Manduca]

Attachment: parameter to set a default parent for new bugs

changes in defparams.pl and /bug/create/create.html.tmpl

Comment 6

[Joel Peshkin]

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

[Joel Peshkin]

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?

Comment 8

[Christian Reis]

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

[Joel Peshkin]

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?

Comment 10

[Dave Miller [:justdave]]

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

[Joel Peshkin]

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?? ]]

Comment 12

[Marc Schumann [:Wurblzap]]

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

Comment 13

[Christian Reis]

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.

Comment 14

[Christian Reis]

(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

[Vlad Dascalu]

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.