Jira Integration issue not moving to done state with merge request

Summary

As of the documentation of the jira-integration we set up one for a project. As Transistion ID we used '41'. An example api request to our jira returned this JSON:

{
expand: "transitions",
transitions: [
{
id: "11",
name: "Backlog",
to: {
self: "https://****/rest/api/2/status/10100",
description: "",
iconUrl: "https://****/",
name: "Backlog",
id: "10100",
statusCategory: {
self: "https://****/rest/api/2/statuscategory/2",
id: 2,
key: "new",
colorName: "blue-gray",
name: "Aufgaben"
}
}
},
{
id: "21",
name: "Selected for Development",
to: {
self: "https://****/rest/api/2/status/10101",
description: "",
iconUrl: "https://****/",
name: "Selected for Development",
id: "10101",
statusCategory: {
self: "https://****/rest/api/2/statuscategory/2",
id: 2,
key: "new",
colorName: "blue-gray",
name: "Aufgaben"
}
}
},
{
id: "31",
name: "Wird Ausgeführt",
to: {
self: "https://****/rest/api/2/status/3",
description: "Dieser Vorgang wird gerade durch den Bearbeiter bearbeitet.",
iconUrl: "https://****/images/icons/statuses/inprogress.png",
name: "In Arbeit",
id: "3",
statusCategory: {
self: "https://****/rest/api/2/statuscategory/4",
id: 4,
key: "indeterminate",
colorName: "yellow",
name: "In Arbeit"
}
}
},
{
id: "41",
name: "Fertig",
to: {
self: "https://****/rest/api/2/status/10001",
description: "",
iconUrl: "https://****/images/icons/status_generic.gif",
name: "Fertig",
id: "10001",
statusCategory: {
self: "https://****/rest/api/2/statuscategory/3",
id: 3,
key: "done",
colorName: "green",
name: "Fertig"
}
}
},
{
id: "51",
name: "Blocked",
to: {
self: "https://****/rest/api/2/status/10400",
description: "Dieser Status wird intern von Jira Software verwaltet.",
iconUrl: "https://****/",
name: "Blocked",
id: "10400",
statusCategory: {
self: "https://****/rest/api/2/statuscategory/4",
id: 4,
key: "indeterminate",
colorName: "yellow",
name: "In Arbeit"
}
}
},
{
id: "61",
name: "In Review",
to: {
self: "https://****/rest/api/2/status/10106",
description: "",
iconUrl: "https://****/",
name: "In Review",
id: "10106",
statusCategory: {
self: "https://****/rest/api/2/statuscategory/4",
id: 4,
key: "indeterminate",
colorName: "yellow",
name: "In Arbeit"
}
}
}
]
}

Therefore '41' should be the desired transistion state.

Steps to reproduce

Setup an jira-integration with gitlab version 11.5.3-ee. Setup an Jira instance with version: v7.12.2. As a workflow in jira we have this one: Bildschirmfoto_2018-12-13_um_13.03.24

The API Request to the transition endpoint returns the JSON above.

Create a Merge Request with a Closing comment. Gitlab now shows 'Closing TEST-1'. Accept the merge request, gitlab now shows in the merge request: 'Closed TEST-1'. Jira issue is not closed. No API call for closing the issue was made in jira direction.

Example Project

every project (testet with 3)

What is the current bug behavior?

No API Request for closing the jira issue

What is the expected correct behavior?

API Request to jira to close the issue

Relevant logs and/or screenshots

In Jira you see:

GitLab GitLab: Mentioned on commit - Merge branch 'bug/WSC-76' into 'master'	
Diese Verknüpfung löschen
GitLab GitLab: Mentioned on commit - Merge branch 'bug/WSC-76' into 'master'	
Diese Verknüpfung löschen
GitLab GitLab: Mentioned on commit - WSC-76: add dynamic titles by route	
Diese Verknüpfung löschen
GitLab GitLab: Mentioned on commit - WSC-76: add enum for justification	
Diese Verknüpfung löschen
GitLab GitLab: Mentioned on commit - WSC-76: don't expose the subjects directly

In gitlab's integration_json.log you see:

{"severity":"INFO","time":"2018-12-07T08:39:56.924Z","service_class":"JiraService","project_id":77,"project_path":"websportspro/frontend","message":"Successfully posted","client_url":"https://****"}
{"severity":"INFO","time":"2018-12-07T08:39:56.933Z","service_class":"JiraService","project_id":77,"project_path":"websportspro/frontend","message":"Successfully posted","client_url":"https://****"}
{"severity":"INFO","time":"2018-12-07T08:39:57.143Z","service_class":"JiraService","project_id":77,"project_path":"websportspro/frontend","message":"Successfully posted","client_url":"https://****"}
{"severity":"INFO","time":"2018-12-07T08:39:57.177Z","service_class":"JiraService","project_id":77,"project_path":"websportspro/frontend","message":"Successfully posted","client_url":"https://****"}
{"severity":"INFO","time":"2018-12-07T09:29:49.875Z","service_class":"JiraService","project_id":77,"project_path":"websportspro/frontend","message":"Successfully posted","client_url":"https://****“}

Output of checks

(If you are reporting a bug on GitLab.com, write: This bug happens on GitLab.com)

Results of GitLab environment info

Expand for output related to GitLab environment info 
System information
System:
Proxy:		no
Current User:	git
Using RVM:	no
Ruby Version:	2.4.5p335
Gem Version:	2.7.6
Bundler Version:1.16.6
Rake Version:	12.3.1
Redis Version:	3.2.12
Git Version:	2.18.1
Sidekiq Version:5.2.1
Go Version:	unknown


GitLab information
Version:	11.5.3-ee
Revision:	588b25b
Directory:	/opt/gitlab/embedded/service/gitlab-rails
DB Adapter:	postgresql
DB Version:	9.6.8
URL:		https://..net
HTTP Clone URL:	https://..net/some-group/some-project.git
SSH Clone URL:	git@.***.net:some-group/some-project.git
Elasticsearch:	yes
Geo:		no
Using LDAP:	yes
Using Omniauth:	yes
Omniauth Providers: bitbucket


GitLab Shell
Version:	8.4.1
Repository storage paths:
  • default: /var/opt/gitlab/git-data/repositories Hooks: /opt/gitlab/embedded/service/gitlab-shell/hooks Git: /opt/gitlab/embedded/bin/git

Results of GitLab application Check

Expand for output related to the GitLab application check 
Checking GitLab Shell ...

GitLab Shell version >= 8.4.1 ? ... OK (8.4.1)
hooks directories in repos are links: ...
3/5 ... ok
2/6 ... ok
5/7 ... ok
16/8 ... repository is empty
19/9 ... ok
19/10 ... repository is empty
20/11 ... ok
15/18 ... ok
15/19 ... ok
16/21 ... ok
7/22 ... ok
7/23 ... ok
7/24 ... ok
7/25 ... ok
7/26 ... ok
7/27 ... ok
7/28 ... ok
7/29 ... ok
7/30 ... ok
8/32 ... ok
25/33 ... ok
9/34 ... ok
14/35 ... ok
10/37 ... ok
30/38 ... ok
8/39 ... ok
8/40 ... ok
8/41 ... ok
8/42 ... ok
5/44 ... ok
3/46 ... ok
16/48 ... ok
15/49 ... ok
32/50 ... ok
4/52 ... ok
4/53 ... ok
10/55 ... ok
33/56 ... ok
34/57 ... ok
34/58 ... ok
12/60 ... ok
12/61 ... ok
14/62 ... ok
35/63 ... ok
3/64 ... ok
9/65 ... ok
9/66 ... ok
9/67 ... ok
5/69 ... ok
15/71 ... ok
10/72 ... ok
30/73 ... ok
9/74 ... ok
9/75 ... ok
33/77 ... ok
9/78 ... ok
38/80 ... ok
22/81 ... ok
9/84 ... ok
39/88 ... ok
15/91 ... ok
27/92 ... ok
26/93 ... ok
40/94 ... ok
9/95 ... ok
9/96 ... ok
41/98 ... ok
41/100 ... ok
24/103 ... ok
15/104 ... ok
12/106 ... ok
12/107 ... ok
2/108 ... ok
9/111 ... ok
2/112 ... ok
20/113 ... ok
21/114 ... ok
20/115 ... ok
3/116 ... ok
19/120 ... ok
3/121 ... ok
Running /opt/gitlab/embedded/service/gitlab-shell/bin/check
Check GitLab API access: OK
Redis available via internal API: OK


Access to /var/opt/gitlab/.ssh/authorized_keys: OK
gitlab-shell self-check successful


Checking GitLab Shell ... Finished


Checking Gitaly ...


default ... OK


Checking Gitaly ... Finished


Checking Sidekiq ...


Running? ... yes
Number of Sidekiq processes ... 1


Checking Sidekiq ... Finished


Checking Reply by email ...


IMAP server credentials are correct? ... no
Try fixing it:
An error occurred: Net::IMAP::Error: connection closed
Check that the information in config/gitlab.yml is correct
For more information see:
doc/administration/reply_by_email.md
Please fix the error above and rerun the checks.
Init.d configured correctly? ... skipped
MailRoom running? ... skipped


Checking Reply by email ... Finished


Checking LDAP ...


Server: ldapmain
LDAP authentication... Success
LDAP users with access to your GitLab server (only showing the first 100 results)




Checking LDAP ... Finished


Checking GitLab ...


Git configured correctly? ... yes
Database config exists? ... yes
All migrations up? ... yes
Database contains orphaned GroupMembers? ... no
GitLab config exists? ... yes
GitLab config up to date? ... yes
Log directory writable? ... yes
Tmp directory writable? ... yes
Uploads directory exists? ... yes
Uploads directory has correct permissions? ... yes
Uploads directory tmp has correct permissions? ... yes
Init script exists? ... skipped (omnibus-gitlab has no init script)
Init script up-to-date? ... skipped (omnibus-gitlab has no init script)
Projects have namespace: ...
3/5 ... yes
2/6 ... yes
5/7 ... yes
16/8 ... yes
19/9 ... yes
19/10 ... yes
20/11 ... yes
15/18 ... yes
15/19 ... yes
16/21 ... yes
7/22 ... yes
7/23 ... yes
7/24 ... yes
7/25 ... yes
7/26 ... yes
7/27 ... yes
7/28 ... yes
7/29 ... yes
7/30 ... yes
8/32 ... yes
25/33 ... yes
9/34 ... yes
14/35 ... yes
10/37 ... yes
30/38 ... yes
8/39 ... yes
8/40 ... yes
8/41 ... yes
8/42 ... yes
5/44 ... yes
3/46 ... yes
16/48 ... yes
15/49 ... yes
32/50 ... yes
4/52 ... yes
4/53 ... yes
10/55 ... yes
33/56 ... yes
34/57 ... yes
34/58 ... yes
12/60 ... yes
12/61 ... yes
14/62 ... yes
35/63 ... yes
3/64 ... yes
9/65 ... yes
9/66 ... yes
9/67 ... yes
5/69 ... yes
15/71 ... yes
10/72 ... yes
30/73 ... yes
9/74 ... yes
9/75 ... yes
33/77 ... yes
9/78 ... yes
38/80 ... yes
22/81 ... yes
9/84 ... yes
39/88 ... yes
15/91 ... yes
27/92 ... yes
26/93 ... yes
40/94 ... yes
9/95 ... yes
9/96 ... yes
41/98 ... yes
41/100 ... yes
24/103 ... yes
15/104 ... yes
12/106 ... yes
12/107 ... yes
2/108 ... yes
9/111 ... yes
2/112 ... yes
20/113 ... yes
21/114 ... yes
20/115 ... yes
3/116 ... yes
19/120 ... yes
3/121 ... yes
Redis version >= 2.8.0? ... yes
Ruby version >= 2.3.5 ? ... yes (2.4.5)
Git version >= 2.9.5 ? ... yes (2.18.1)
Git user has default SSH configuration? ... yes
Active users: ... 19
Elasticsearch version 5.1 - 5.5? ... no (6.2.4)
For more information see:
doc/integration/elasticsearch.md


Checking GitLab ... Finished

Note: Yes we now mail is not working, this issue should not be related to it.

Possible fixes

(If you can, link to the line of code that might be responsible for the problem)

Best regards Henry.

We tried to get support with ticket: 109640