source-integration icon indicating copy to clipboard operation
source-integration copied to clipboard

Mantis GitLab Plugin Extension - Add more Status Changes

Open promat01 opened this issue 5 years ago • 4 comments

Hello, I am using the Mantis GitLab Plugin and I would like to have an extension for the Plugin. It would be great to implement another status change when linking a Mantis Ticket and a GitLab Issue. Another status change after a merge has finished would also be nice. Is there already some extension for this plugin or could you please add this to an upcoming plugin version?

Thank you and best Regards,

promat01 avatar Aug 17 '18 14:08 promat01

Your requirement is not very clear. Please explain your process / workflow.

status change when linking a Mantis Ticket and a GitLab Issue

Does that mean you're using both Mantis and Github issues in parallel ?

Another status change after a merge has finished would also be nice.

You can reference an issue id in the merge commit (e.g. Fixes #xxx) so that

In any case, the plugin's purpose is limited to integrating with a repository - not with an application managing that repository. In other words, it only deals with commits, and not with activity happening outside of the repository; it has no concept of Issues (outside of Mantis) or merge/pull requests, etc.

dregad avatar Aug 20 '18 11:08 dregad

Another status change after a merge has finished would also be nice.

@dregad I can provide my impression of this. What @promat01 probably meant, that currently Source supports only two function related to commit messages: making links between commits and mentioned issues and resolving (moving to any state defined in settings) the issues mentioned in the commit.

Suggestion could be to have something like: When commit is is some branch other than master mentions "fixed #1345", Source should be able to move the issue to some intermediate state like resolved (or any defined in settings). And when the same commit gets into master with the same commit message "fixed #1345", Source should be able to move this issue into some different status like closed.

@promat01 have you tried to set up Source watching only master branch? So Source will close issues only when the fixes were actually merged.

okainov avatar Aug 21 '18 15:08 okainov

Hey, thanks for the reply, sorry for the late answer. I want the following workflow: 1st: Liking between Mantis Ticket and GitLab issues #123 + change into status "in progress" (whatever this status is called) just another configuration option for the Plugin to choose the status here (same as there ist when u use fixed #123) 2nd: Another regular expression + Status change from "in progress" (or whatever you call the status) to "internal test" (or whatever you call the status) when you did your changes and you want to create a merge request. So everyone knows, there is a merge request, which they should have a look at. 3rd: Merge finished -> set to closed (or whatever status). I can already use this step in the Plugin, as you mentioned. #fixed #123

Would be great if you can help me with that or even implement this in the main version of the plugin. The current plugin version is really nice, but I think there should be some more steps to automize the tickets, which would be very helpful for me. Thanks and BR

promat01 avatar Aug 30 '18 07:08 promat01

I still get the feeling that what you're asking for is not directly related to source integration (at least, the way it's currently implemented in this plugin, and how I've been using that in the past).

What I mean, is that it's not a source repository commit that should (IMHO) trigger an issue's status to In Progress (it normally happens before that).

I'll agree that having a 3rd set of RegEx to trigger a second status change in addition to Resolved might be useful in your workflow of closing an Issue when the corresponding pull request is merged; however please note doing that would require the person merging the PR to manually reference the proper issue in the commit message.

Of course this would have to be generic (i.e. in main Source plugin), and not Gitlab-specific.

In any case, this sounds like a fairly important change, and one that I currently I have neither the time nor the interest to implement myself. If you are willing to contribute this feature, I will gladly review your pull request.

dregad avatar Aug 30 '18 16:08 dregad