Closed
Bug 232241
Opened 21 years ago
Closed 15 years ago
Need a way to unconditionally add a comment
Categories
(Bugzilla :: Creating/Changing Bugs, enhancement)
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: gerv, Unassigned)
References
Details
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•21 years ago
|
||
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.
Reporter | ||
Comment 2•21 years ago
|
||
> 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•21 years ago
|
||
>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•21 years ago
|
||
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•21 years ago
|
||
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•21 years ago
|
||
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•21 years ago
|
||
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.
Reporter | ||
Comment 8•21 years ago
|
||
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•21 years ago
|
||
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...
Reporter | ||
Comment 10•21 years ago
|
||
> * 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•21 years ago
|
||
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.
Updated•19 years ago
|
QA Contact: mattyt-bugzilla → default-qa
![]() |
||
Updated•18 years ago
|
Assignee: myk → create-and-change
Reporter | ||
Comment 12•15 years ago
|
||
There is now an API for this, and you can click through to just add the comment if you mid-air. Gerv
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•