Status and resolution not set when issue is fixed

[Nick-Hall]

I have set up GitHub source integration for the Gramps Project and our bug tracker. We are using Source Control Integration 2.0.3 and Source GitHub Integration 2.0.0.

When a bug is fixed in a maintenance branch (maintenance/gramps50), the changeset is attached to the issue and a fixed message is created. However the issue is not set to "resolved" and "fixed".

In the configuration, "Resolve Fixed Issues" is set. "Bug Fixed Status" is set to "resolved" (I also tried "[Resolved Status]") and "Bug Fixed Resolution" is set to "fixed".

What am I doing wrong?

I also tried setting "Bug Fixed Assign To Committer", although I would prefer the issue assigned to the author or left unchanged. This resulted in a webhook timeout.

[dregad]

How did you reference the issue in the commit message ? Have a look at the regexes in the plugin configuration; there are 2 sets, for resolution it should be Fix|es|ed or Resolve|s|d #xxx

If that is correctly written, and the settings are correct, then maybe the author (or committer as fallback) user's account does not have the privilege to handle issues ?

It may also depend on your Mantis' settings for bug_resolved_status_threshold, bug_resolution_fixed_threshold and bug_resolution_not_fixed_threshold

Have a look at the code for full details on the resolution logic.

[Nick-Hall]

Thanks for your help. After examining the code, I now have it working.

The problem was that I wrongly interpreted a couple of the settings. The "Bug Fixed Assign To Committer" was the setting I needed, but I found the description misleading. Tooltips to describe this and the "Resolve Fixed Issues" setting would have been useful. The webhook timeout was totally unrelated.

[dregad]

@Nick-Hall thanks for the feedback.

If you would be so kind as to provide what you'd like to see as tooltips, and how to amend the description to make it clearer, I'll gladly improve that.

[luzpaz]

@Nick-Hall good point, I also would like to know what tooltips you suggest?

[Nick-Hall]

Sorry, I forgot about this PR.

Renaming "Bug Fixed Assign To Committer" to something like "Automatically Update Issue", and swapping its position with the "Resolve Fixed Issues" setting would be clearer. The "Bug Fixed Assign To Committer" setting is required to enable a feature. The "Resolve Fixed Issues" setting customises the feature.

Tooltips just provide extra information as you have done for "Changeset linking". For example, the tooltip for "Repository Statistics" could be "Add columns to show the number of changesets, files and issues in the repository listing".

[fcenedese]

Actually I'd keep the descriptions but change the code. In Source.API.php

function Source_Process_Changesets( $p_changesets, $p_repo=null ) {

instead of skipping closing completely if the handler is not set
(meaning "Bug Fixed Assign To Committer" is not enabled)

	} elseif( $t_handler && $t_handler_id !== null ) {

do it like this

	} elseif( $t_handler_id !== null ) {

and only check the handler setting for the real assignment

		if ($t_handler) {
			if( $t_bug->handler_id != $t_handler_id ) {
				$t_bug->handler_id = $t_handler_id;
				$t_update = true;
			}
		}

That way auto closing still works even if the "Bug Fixed Assign To Committer"
option is not set. In my view the code then works as described by the options.

[Heavenfighter]

I agree with fcenedese

[dregad]

The current behavior is by design actually (see #80), as documented in the code:

source-integration/Source/Source.API.php

Lines 380 to 382 in e374fec

	} elseif( $t_handler && $t_handler_id !== null ) {
	# We only resolve the issue if an authorized handler has been
	# identified; otherwise, it will remain open.

I did not look in detail to confirm for sure, but if I'm not mistaken what @fcenedese suggests would allow resolved issues not to be assigned at all, which feels strange to me. What do you think ?

Anyway, I'll have a closer look as time allows.

[fcenedese]

(Sorry for replying to the mailing list)

I just think that the naming of this option doesn't match its function.
Right now it just says "assign name", but unchecking it disables
issue closing completely. So it does (almost?) the same as the
feature box. I find this counter intuitive.

If you use my code change and enable the "assign name" box by
default then you get the same behavior as it is now I think. However
disabling it allows to close an issue without changing the assignee
which is not possible right now. If that means that an issue might be
closed without a user assigned to it then so be it, that's why we
unchecked this feature. Usually we already assigned the issues
beforehand so they already have an assignee. And if the issue is
closed by a commit then it's also visible who did the commit. The
assignee does not need to be the same as the one fixing/closing
the issue. For us mantis is a bug tracker, not more. We already
have VCS to track of who did what.

Of course you can keep the current behavior but then at least you
need to change the wording of the check box as it definitely doesn't
describe its function right now. And we'd still keep our local mantis
patched to get the desired functionality. But looking at the comments
in the issues and mailing lists we're not the only ones struggling
with this.

Thanks