OK, here's a proposal to fix this issue as suggested by Kristis.
The new parameter is optional, so it doesn't break existing implementations. As I noticed, just the bugzilla impl will support this kind of status change at the moment.
E.g. in bugzilla's map annotate:
my $bugzilla_bug_status_map = {
"ASSIGNED" => { name => "ASSIGNED",
.........
accepts_data_as_resolution => 1,
.........
};
Be aware that the new assignee will be passed as resolution to
integration_change_bug_resolution, not as $resolution_data as expected.
Here's the patch to Bugtracker.pm.in
Bugtracker.pm.in.patch
Description: Binary data
On Dec 27, 2007, at 8:14 , Kristis Makris wrote:
Bugtracker.pm:resolution_change_check should be handling this, and in the individual backends their $bug_status_map should support flagging the resolutions that have such an empty resolution state.On 12/26/07, Oliver Schäfer <[EMAIL PROTECTED]> wrote: http://bugzilla.mkgnu.net/show_bug.cgi?id=547#c31We have to catch it in Bugzilla.pm.in ? On Dec 26, 2007, at 12:56 , Oliver Schäfer wrote: > New problem for 'status 8: assigned [EMAIL PROTECTED] > services.com' > > How do we annotate an empty resolution in the log_message? With the > current setup we would need something like: > > status 8: assigned XXX [EMAIL PROTECTED] > > but it's not very nice. > > ******************************************* > ** > ** > ** Scmbug error 7: Invalid resolution '[EMAIL PROTECTED] > services.com' when resolving bug '8' from state 'REOPENED' to state > 'assigned'. Instead, a valid resolution could be the . > ** > ** > ******************************************* >
_______________________________________________ scmbug-users mailing list [email protected] http://lists.mkgnu.net/cgi-bin/mailman/listinfo/scmbug-users
