232241 - Need a way to unconditionally add a comment

Status: RESOLVED WORKSFORME

(Bugzilla :: Creating/Changing Bugs, enhancement)

Description

[Gervase Markham [:gerv]]

It would be cool if there was a URL you could call, with appropriate Bugzilla
login parameters, which unconditionally added the given comment to the end of a
bug. This would be handy for all sorts of integration things, e.g. CVS
integration, where the commitinfo script wants to append the checkin log without
worrying about any other fields, mid-air collisions or the like.

Gerv

Comment 1

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

Great idea.  Our current code assumes all fields will be submitted and complains
if any aren't.  We should distinguish between fields with empty values and those
that don't exist in the input and stop requiring all fields to exist.  That
would open the door for not only this fix but for many customized bug
modification interfaces.

Comment 2

[Gervase Markham [:gerv]]

> We should distinguish between fields with empty values and those
> that don't exist in the input and stop requiring all fields to exist.

That may be easier said than done. Browser-based interfaces make that hard for
some UI types. For example, checkboxes don't appear in the URL stream if they
are unchecked. I don't know if this problem is apparent with other types too.

I'm also slightly concerned about your Pandora's box of "any customized bug
modification interfaces." I think that any operation other than the adding of a
comment should be subject to mid-air collision protection. Adding a comment is a
special case (and one which people want to do a lot) - hence this bug.

Gerv

Comment 3

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

>That may be easier said than done. Browser-based interfaces make that hard for
>some UI types. For example, checkboxes don't appear in the URL stream if they
>are unchecked. I don't know if this problem is apparent with other types too.

It's not.  checkboxes are the only element for which this is a problem, and we
have very few in show_bug.cgi.  Even checkboxes can be dealt with fairly easily
with corresponding hidden fields.

>I'm also slightly concerned about your Pandora's box of "any customized bug
>modification interfaces." I think that any operation other than the adding
>of a comment should be subject to mid-air collision protection.

I think that depends on the operation and shouldn't be prejudged, but point well
taken about comments being a special case.  I won't morph your bug out of control.

Comment 4

[David Swegen]

So I assume this would be best done as a new cgi? That would keep it simple.
Having had a brief look at the scripts in question (mainly process_bug.cgi), I
would assume the only things that would need checking are credentials and that
the requested bug(s) exist.

Is it also intended for human consumption?

What I'd like to see is ability to add comments to multiple bugs at once,
optionally failing the whole operation if any bugs don't exist, or access is
denied to any bugs. Also a nicely parseable results page would be great.

If this sounds reasonable I'd be happy to have a go at doing it.
(sorry for the wibbly nature of this comment - I'm juggling tasks ATM)

Comment 5

[David Swegen]

Justdave kindly clarified the dontchange parameter, and it almost does what this
bug is looking for (at least as far as I'm concered). Problems are:

* Midair collision is still possible, I believe.
* Poor error reporting from a scripting POV. The fact that it stops at the first
error is a PITA, as my script will have to resubmit the request until it only
contains valid bug ids. Which is grotty. And slow.
* Related to the above: Parsing the resulting output is hardly script friendly,
and will probably, as time goes by, become more and more flaky due to
localisation changes.
* When writing scripts to interface to this it is rather tedious having to try
and figure out what parameters are obligatory.

Comment 6

[David Swegen]

I'm about ready to tackle this one. How would people like it: as a new
standalone cgi (which is my preference), or by modding process_bug.cgi?

Comment 7

[Dave Miller [:justdave]]

How about making an XML or RDF or something output template for process_bug.cgi?

I'm pretty sure the edit-multiple stuff currently has no mid-air protection, so
you shouldn't have to worry about that (for now).  It's possible that it might
at some point in the future, but due to the other factors involved in changing
many bugs at once, I'm sure there will be overrides for things like comments and
CCs by then.  Especially if we have a mechanism like this to keep from breaking.

Comment 8

[Gervase Markham [:gerv]]

IMO, we don't want a separate CGI. If we have one, we'll get requests like "Oh,
can we use this to change the status as well?" and before we know it we've got a
second process_bug.cgi.

Dave said in another bug that the right fix is for process_bug to distinguish
between setting a field to a blank value, and the field not being present in the
query string at all. That way, you could specify a subset of fields in the URL,
with an implicit "and leave the rest alone." 

This would mean we could throw away our --do_not_change-- hacks for multiple bug
editing, and make it much easier for outside apps to integrate with Bugzilla at
the same time, changing whatever they needed to.

Gerv

Comment 9

[David Swegen]

OK, process_bug.cgi it is. So these are the changes I intend to do initially:
* If the only change is to comments make sure that midair isn't checked (which
may or may not already be the case)
* Don't bomb out at the first error, but carry on and report all errors at the
end (or would this be better as an option?)

I'm going to assume that making these changes will give me enough of a feel for
how process_bug is constructed to make the slightly larger changes being
suggested here. Ho hum, we'll see how it goes...

Comment 10

[Gervase Markham [:gerv]]

> * If the only change is to comments make sure that midair isn't checked (which
> may or may not already be the case)

This is not currently the case, and I don't think this should be the default
behaviour. Sometimes a change made by someone else totally invalidates what you
were about to say - the midair screen is very useful in this case.

I suspect, however, that doing "make my changes anyway" from the midair screen
submits the same info but with an extra parameter to say "bypass midair". So in
one sense, we already do what you want...

Gerv

Comment 11

[Dave Miller [:justdave]]

unconditionally not midairing on a comment would be a bad thing.  Doing it from
edit-multiple (and thus, this mechanism, since I'm guessing it would be
engineered to look like it's coming from edit-multiple) probably wouldn't be so
bad.  I'm not sure midair checks are even made when you come from edit-multiple
anyway, so this shouldn't even be an issue.

Doing "submit my change anyway" only submits with a new timestamp (the time the
midair form was loaded).  If someone else has made additional changes between
the time you got the midair screen, and the time you clicked "submit anyway"
you'll get a midair again.

An automated process wouldn't be sending a delta_ts value, and thus wouldn't get
midair protection anyway.

Comment 12

[Gervase Markham [:gerv]]

There is now an API for this, and you can click through to just add the comment if you mid-air.

Gerv