shotgunsoftware / sg-jira-bridge Goto Github PK

Does anyone have any info if logged time currently gets synced between Shotgun and Jira?

When I look at the logs I can see that the event is getting received when I log time from the Shotgun side:
DEBUG:plugin.sg_jira_event_trigger.process_event:Posting event {'entity_id': 17286, 'attribute_name': 'time_logs_sum', 'in_create': True, 'entity_type': 'Task', 'old_value': 0, 'new_value': 300, 'field_data_type': 'duration', 'type': 'attribute_change'} to https://127.0.0.1/sg2jira/default/Task/17286

However I don't see any change on the Jira side... I also don't seem to receive any time logged events from the Jira side (at least the logs don't indicate that)

The bridge is running on an AWS server on Ubuntu 20.04.2 LTS and I'm using Tempo timesheets with Jira.

The documentation doesn't make it 100% clear if they've even implemented this yet but if they haven't I might take a stab myself (although custom handlers do look pretty menacing)

Cheers,
Jameson

Hi,

This relates to our Jira Cloud testing in #26. I noticed those exceptions being raised, although they do not seem to affect the web app so far:

2019-09-17 08:33:27,712 INFO [bridge] Successfully read settings from ***/sg-jira-bridge/settings.py
2019-09-17 08:33:28,038 INFO [shotgun_session] Connected to https://***.shotgunstudio.com.
2019-09-17 08:33:28,713 INFO [jira_session] Connected to https://***.atlassian.net.
2019-09-17 08:35:38,089 INFO [note_comment_handler] Jira issue ***-28 Comment 11918 updated. Syncing to Shotgun Note (7321)
2019-09-17 08:35:46,549 INFO [note_comment_handler] Shotgun Note (7322) added. Adding as a comment on Jira Issue ***-28
2019-09-17 08:35:47,011 INFO [note_comment_handler] Updating Shotgun Note (7322) with Jira comment key ***-28/11920
2019-09-17 08:35:47,660 INFO [note_comment_handler] Shotgun Note (7322) updated. Syncing to Jira Issue ***-28 Comment 11920
2019-09-17 08:35:52,302 ERROR [webapp] 13.237.238.24 - code 400, message Bad request syntax ('\x16\x03\x03\x01')
Traceback (most recent call last):
  File "/usr/local/lib/python2.7/SocketServer.py", line 293, in _handle_request_noblock
    self.process_request(request, client_address)
  File "/usr/local/lib/python2.7/SocketServer.py", line 321, in process_request
    self.finish_request(request, client_address)
  File "/usr/local/lib/python2.7/SocketServer.py", line 334, in finish_request
    self.RequestHandlerClass(request, client_address, self)
  File "/usr/local/lib/python2.7/SocketServer.py", line 657, in __init__
    self.finish()
  File "/usr/local/lib/python2.7/SocketServer.py", line 716, in finish
    self.wfile.close()
  File "/usr/local/lib/python2.7/socket.py", line 283, in close
    self.flush()
  File "/usr/local/lib/python2.7/socket.py", line 307, in flush
    self._sock.sendall(view[write_offset:write_offset+buffer_size])
  File "/usr/local/lib/python2.7/ssl.py", line 745, in sendall
    return socket.sendall(self, data, flags)
  File "/usr/local/lib/python2.7/socket.py", line 228, in meth
    return getattr(self._sock,name)(*args)
error: [Errno 32] Broken pipe
2019-09-17 08:35:52,814 INFO [note_comment_handler] Shotgun Note (7322) updated. Syncing to Jira Issue ***-28 Comment 11920
2019-09-17 08:35:57,600 ERROR [webapp] 13.237.238.24 - code 400, message Bad request syntax ('\x16\x03\x03\x01')
Traceback (most recent call last):
  File "/usr/local/lib/python2.7/SocketServer.py", line 293, in _handle_request_noblock
    self.process_request(request, client_address)
  File "/usr/local/lib/python2.7/SocketServer.py", line 321, in process_request
    self.finish_request(request, client_address)
  File "/usr/local/lib/python2.7/SocketServer.py", line 334, in finish_request
    self.RequestHandlerClass(request, client_address, self)
  File "/usr/local/lib/python2.7/SocketServer.py", line 657, in __init__
    self.finish()
  File "/usr/local/lib/python2.7/SocketServer.py", line 716, in finish
    self.wfile.close()
  File "/usr/local/lib/python2.7/socket.py", line 283, in close
    self.flush()
  File "/usr/local/lib/python2.7/socket.py", line 307, in flush
    self._sock.sendall(view[write_offset:write_offset+buffer_size])
  File "/usr/local/lib/python2.7/ssl.py", line 745, in sendall
    return socket.sendall(self, data, flags)
  File "/usr/local/lib/python2.7/socket.py", line 228, in meth
    return getattr(self._sock,name)(*args)
error: [Errno 32] Broken pipe

Looking at the service code, I do not see support to specify the cert and key files, and have them passed to run_server in the webapp.py.

This is a must for companies (such as mine) that require SSL support for all internal sites.

Hi,

This refers directly to #26 (comment). I'm creating a new ticket because the original issues encountered in #26 are essentially solved.

So it appears that the bridge does not push comments from Jira back to Shotgun, the core of the problem being that Shotgun Notes & Replies for a Task are like a tree while Jira Comments for an Issue are sequential within a thread. I was suggesting to simply inline everything on the Jira end:

• Shotgun Notes and Note Replies ---> Jira Comments
• Jira Comments ---> Notes

I reckon that people will get use and understand that limitation.

As Jira is updating from 2.0.0.sg.3 to 3.5. It seems has dropped equal function for Jira.resources.User class.
Here is Jira-2.0.0 Version

And here is Jira-3.5.0 Version

Thus the direct equal function for comparing two jira user which has Jira.resources.User which not return the desired result. And changing assignee will not be able to sync to Jira properly.

For example, the following code will never proceed since it is comaping two calss instance.
https://github.com/shotgunsoftware/sg-jira-bridge/blob/master/sg_jira/handlers/entity_issue_handler.py#L436C21-L436C21

The update for a synced comment does not propagate to Shotgun correctly. The reason for this being that the body is malformed based on the sg-jira-bridge's expectation.

This error is not one of the known issues (in fact, it specifically mentions it should be supported):

Shotgun Notes contain a subject and content, while Jira Comments have only a body. When syncing Notes from Shotgun to Jira, a special formatting is used to mimic the structure that Shotgun uses. Updates to a Comment in Jira must retain this formatting otherwise the Comment will not sync back to Shotgun.

Source documentation.

The issue becomes apparent if you compare the regex in source compared to what message comes in. The webapp gives the following warning:

2020-05-27 15:07:40,015 WARNING [note_comment_handler] Unable to process Jira Comment comment_updated event. Invalid Jira Comment body format. Unable to parse Shotgun subject and content from '{panel:bgColor=#deebff}
Kevin Chi Yan's Note on TestAsset

Testing out Shotgun comment replies / edits from Jira.

Edit from Jira (Try 2)
{panel}'

The regex that the handler is comparing to is r"\{panel:title=([^\}]*)\}(.*)\{panel\}" which makes sense since it's posted with the title as well. I guess in some update Jira now converts the title attribute into the bold markup above. (See: https://github.com/shotgunsoftware/sg-jira-bridge/blob/master/sg_jira/handlers/note_comment_handler.py#L95)

What I'm not sure of is if this is only a problem in certain versions (or certain settings within Jira?)

Edit: I just saw the #24 Pull Request addressing this issue. I'm closing this one.

Hello. I'm trying to setup the Shotgun x Jira integration following the instructions on https://developer.shotgunsoftware.com/sg-jira-bridge/quickstart.html.

I'm getting 401 while authentication to a Jira Cloud instance. I've double checked the username and password, I've also tried to login using API keys without success.

2019-09-02 14:53:37,026 ERROR [bridge] maximum recursion depth exceeded while calling a Python object
Traceback (most recent call last):
  File "/app/sg-jira-bridge-master/sg_jira/bridge.py", line 138, in get_bridge
    sg_http_proxy=shotgun_settings.get("http_proxy"),
  File "/app/sg-jira-bridge-master/sg_jira/bridge.py", line 72, in __init__
    jira_secret
  File "/app/sg-jira-bridge-master/sg_jira/jira_session.py", line 35, in __init__
    jira_site, *args, **kwargs
  File "/usr/local/lib/python2.7/site-packages/jira/client.py", line 462, in __init__
    user = self.session(auth)
  File "/usr/local/lib/python2.7/site-packages/jira/client.py", line 2446, in session
    r = self._session.post(url, data=json.dumps(authentication_data))
  File "/usr/local/lib/python2.7/site-packages/jira/resilientsession.py", line 154, in post
    return self.__verb('POST', url, **kwargs)
  File "/usr/local/lib/python2.7/site-packages/jira/resilientsession.py", line 125, in __verb
    response = method(url, timeout=self.timeout, **kwargs)
  File "/usr/local/lib/python2.7/site-packages/requests/sessions.py", line 581, in post
    return self.request('POST', url, data=data, json=json, **kwargs)
  File "/usr/local/lib/python2.7/site-packages/requests/sessions.py", line 533, in request
    resp = self.send(prep, **send_kwargs)
  File "/usr/local/lib/python2.7/site-packages/requests/sessions.py", line 653, in send
    r = dispatch_hook('response', hooks, r, **kwargs)
  File "/usr/local/lib/python2.7/site-packages/requests/hooks.py", line 31, in dispatch_hook
    _hook_data = hook(hook_data, **kwargs)
  File "/usr/local/lib/python2.7/site-packages/jira/client.py", line 208, in handle_401
    self.init_session()
  File "/usr/local/lib/python2.7/site-packages/jira/client.py", line 224, in init_session
    self.start_session()
  File "/usr/local/lib/python2.7/site-packages/jira/client.py", line 238, in start_session
    self._get_session(self.__auth)
  File "/usr/local/lib/python2.7/site-packages/jira/client.py", line 2446, in session
    r = self._session.post(url, data=json.dumps(authentication_data))

Did anyone had issues with this?

It looks like the Next-Gen Jira projects create duplicate issue types with a project scope of the new project. Even in the Jira user with API Token does not have access to that project the issue_types come up in the Jira Python 2.0+ client.issue_types() method, which means that the jira_session.py#480 self.issue_type_by_name(issue_type) call returns a scoped issue type which most projects can't use.

It looks like using issuetypeNames=issue_type in the self.createmeta(...) on line 489 would be preferable to using that queried id, since the createmeta data will be correctly project scoped.

I was under the impression multiple shotgun projects could map to a single Jira project. What is the impact of circumventing the checks? I read elsewhere that it was possible. Does the bridge support multiple Jira projects?

The newer version of Jira added a parent field. Is it possible to get support for this field in associating issues versus using a link?

Hello,

I'm following this tutorial while setting up a bridge between shotgrid and Jira.
After running the webapp.py script and hitting the port 9090 with curl I'm getting this error:

Have I configured something wrong?

Below I highlighted the line causing the error. In my case the content variable is a string containing the HTML response with <h2>The server is alive</h2>

I'm on the latest commit on master, tag: v0.3.1

I'm trying to troubleshoot event handler errors on SG Jira Bridge.
The event daemon appears to be processing properly and sending event traffic to the localhost SG Jira Bridge site.
However, I always get handling errors not sure where or how it's failing.
Below is an example debug log of what I'm receiving from the SG Jira Bridge web service.

2022-02-04 10:33:37,729 DEBUG [task_issue_handler] Rejecting Shotgun event for unsupported Shotgun field step: {u'entity_id': 17444, u'entity_type': u'Task', u'project': {u'type': u'Project', u'id': 617, u'name': u'Retro Test Project'}, u'meta': {u'entity_id': 17444, u'attribute_name': u'step', u'in_create': True, u'entity_type': u'Task', u'old_value': None, u'new_value': {u'valid': u'valid', u'type': u'Step', u'uuid': u'c400dd58-4bec-11e9-8487-0242ac110006', u'name': u'Design', u'id': 129}, u'field_data_type': u'entity', u'type': u'attribute_change'}, u'user': {u'type': u'HumanUser', u'id': 1079, u'name': u'Ethan Mcdonald'}, u'session_uuid': u'c509eb22-85d7-11ec-8f1a-0242ac110007'}

Hi,

This relates to our Jira Cloud testing in #26. It is not obvious from the documentation and the code implies that it is not doable, e.g.

Cheers,

Thomas

pylint-sg-jira-bridge.txt

Used bandit to identify the following issue...

Run started:2019-09-17 07:22:30.845048

Test results:
>> Issue: [B108:hardcoded_tmp_directory] Probable insecure usage of temp file/directory.
   Severity: Medium   Confidence: Medium
   Location: sg-jira-bridge/service.py:145
   More Info: https://bandit.readthedocs.io/en/latest/plugins/b108_hardcoded_tmp_directory.html
144             "--pid_file",
145             default="/tmp/sg_jira.pid",
146             help="Full path to a file where to write the process pid.",

--------------------------------------------------
>> Issue: [B108:hardcoded_tmp_directory] Probable insecure usage of temp file/directory.
   Severity: Medium   Confidence: Medium
   Location: sg-jira-bridge/settings.py:86
   More Info: https://bandit.readthedocs.io/en/latest/plugins/b108_hardcoded_tmp_directory.html
85                  # this location should be updated to where you store logs
86                  "filename": "/tmp/sg_jira.log",
87                  "maxBytes": 1024 * 1024,
88                  "backupCount": 5
89              },
90          },
91      }
92      # Sync settings. Keys are settings name.
93
94      # Add the examples folder to the Python path so the syncers can be loaded.

I'd probably update the defaults to /var/run/ for the PID, and /var/log/ for the log file.