Change issue status after merge request is merged.

[sandratatarevicova]

This pull request adds support for changing issue status after merging pull request / merge request. The target status and journal author is configurable using environment variables REDMINE_MERGE_REQUEST_LINKS_AFTER_MERGE_STATUS, REDMINE_MERGE_REQUEST_LINKS_GITLAB_REDMINE_USER_ID and REDMINE_MERGE_REQUEST_LINKS_FIXING_KEYWORD_PATTERN.

[tf]

Thanks for your contribution. I'll be on vacation next week, but will have a look afterwards. I took a quick peak at the code and saw that the new features are not covered by tests yet. I imagine those new cases will fit in well with the existing unit tests.

[tf]

This looks like a good first step. Once tests are added, this can be merged.

[sandratatarevicova]

@tf If this PR will be merged, we might use the REDMINE_MERGE_REQUEST_LINKS_GITLAB_REDMINE_USER_ID to create journals when merge request is created or updated. Do you think it is good idea? Should I create some issue? :-)

[tf]

we might use the REDMINE_MERGE_REQUEST_LINKS_GITLAB_REDMINE_USER_ID to create journals when merge request is created or updated.

Oh that could be really cool! Let's do it in a separate PR, though, once this one is merged.

Just now i noticed the "GITLAB" in the name of the variable REDMINE_MERGE_REQUEST_LINKS_GITLAB_REDMINE_USER_ID. What do you think about just calling it REDMINE_MERGE_REQUEST_LINKS_REDMINE_USER_ID instead since it will also be used for journal entries caused by GitHub or Gitea web hook calls?

[sandratatarevicova]

Just now i noticed the "GITLAB" in the name of the variable REDMINE_MERGE_REQUEST_LINKS_GITLAB_REDMINE_USER_ID. What do you think about just calling it REDMINE_MERGE_REQUEST_LINKS_REDMINE_USER_ID instead since it will also be used for journal entries caused by GitHub or Gitea web hook calls?

You are right, the GITLAB in the name of the variable does not make sense. It was probably some thinko :-) Fixed.