-
Notifications
You must be signed in to change notification settings - Fork 14
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Jira Cloud: Almost there! #26
Comments
Seems like I managed to get rid of the history so I can put the updated content again: Follow-up on Zendesk Ticket #105065. So I was looking at the jira_basic_auth branch and we started to patch the code in a similar way, actually a bit more so that our webserver works with HTTPS and our certificates. Here is a diff between our branch and v0.1_enhancements: $ git diff v0.1_enhancements
diff --git a/sg_jira/bridge.py b/sg_jira/bridge.py
index f859509..953a174 100644
--- a/sg_jira/bridge.py
+++ b/sg_jira/bridge.py
@@ -67,7 +67,7 @@ class Bridge(object):
self._jira = JiraSession(
jira_site,
- auth=(
+ basic_auth=(
jira_user,
jira_secret
),
@@ -212,7 +212,8 @@ class Bridge(object):
:returns: A string with the username.
"""
- return urllib.unquote_plus(self.jira.current_user())
+ # TODO: "JIRA.current_user()" returns None has "JIRA._myself" does not exist for us.
+ return urllib.unquote_plus(self.jira.current_user() or os.environ['SGJIRA_JIRA_USER'])
@property
def jira(self):
diff --git a/webapp.py b/webapp.py
index e54f65e..5743c40 100644
--- a/webapp.py
+++ b/webapp.py
@@ -477,7 +477,7 @@ def run_server(port, settings, keyfile=None, certfile=None):
"""
httpd = Server(
settings,
- ("localhost", port), RequestHandler
+ ("", port), RequestHandler
)
if keyfile and certfile:
# Activate HTTPS. Essentially getting rid of sg-jira-bridge Log
shotgunEvents Log
The User email visibility setting in our Jira Cloud instance is set to Public. |
@manneohrstrom : Feel free to re-open the ticket at your convenience and sorry for the fuss! |
Thanks Thomas! No fuss at all :) - I'll reopen it and will let the team know! |
hello Thomas, quick heads up that we issued a quick fix for one of your problems: Not being able to retrieve users email addresses will cause problems down the line: they are used to match Jira to Shotgun users (e.g. for assignments). We run a test setup with an admin user for the bridge and are able to get Jira users email address. I don't think we changed the email privacy setting anywhere. Could that be an option for you? |
Yeah that what I was gathering from the code. We will have to think about what it means from a security standpoint to have a admin user doing that. |
By the way, you are testing with Jira Cloud right? |
Indeed
Stéphane Deverly
Le 10 sept. 2019 à 00:28, Thomas Mansencal <[email protected]<mailto:[email protected]>> a écrit :
By the way, you are testing with Jira Cloud right?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub<#26?email_source=notifications&email_token=AJLYXREZM4JEOJJ7ADE2FVTQI3EYJA5CNFSM4ISY7YE2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD6JHIUA#issuecomment-529691728>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AJLYXRHNCCQUG7YT5SDGXFDQI3EYJANCNFSM4ISY7YEQ>.
|
Thanks! How hard would it be for you guys to try with a regular user? I'm not very comfortable with the requirement for it to be admin. I will also separately raise a ticket with Atlassian tomorrow to try understanding what is going on. |
Update from our end, so it turns out that irrespective of the User email visibility setting in our Jira Cloud instance being set to Public, a logged user is able to get the emailAddress field through the API. This is executed on our Droplet with the Python environment the Jira Bridge uses and the same user: >>> from jira import JIRA
>>> jr = JIRA('https://***.atlassian.net', basic_auth=('***@***.com', '***'))
>>> jr.issue('***').fields.creator.emailAddress
u'***@***.com'
>>> jr.issue('***').fields.reporter.emailAddress
u'***@***.com' It makes me rather confused over what is currently not working. Maybe I'm not using the Bridge correctly or as it was intended. The original logs I provided are generated upon creating a Task in Shotgun and ticking the Sync in Jira tickbox, my expectations would be that it would create a matching issue in Jira. Is this the case? |
So looking at the event here: https://github.com/shotgunsoftware/sg-jira-bridge/blob/jira_basic_auth/sg_jira/syncer.py#L160 We don't have an {u'entity_id': ***, u'entity_type': u'Task', u'project': {u'type': u'Project', u'id': *, u'name': u'*'}, u'meta': {u'entity_id': *, u'attribute_name': u'color', u'in_create': True, u'entity_type': u'Task', u'old_value': None, u'field_data_type': u'color', u'new_value': u'pipeline_step', u'type': u'attribute_change'}, u'user': {u'type': u'HumanUser', u'id': *, u'name': u'*'}, u'session_uuid': u'*'}, My understanding it that this is actually an event from Shotgun, so I'm puzzled as to why it is being handled by a definition called |
Hi, Still no luck with the
It really does feel like the Jira Events processing code processes Shotgun Events and vice versa. I have checked again our configuration and I think we are doing everything as per your documentation. |
Hello, it seems your log is about accepting a Jira event, so not sure what you mean about Jira processing code processing SG event? To be sure, you can stop the SG event daemon, so you will only get Jira to SG events being processed. |
@gplsteph : Did you see the previous one though? #26 (comment) |
@KelSolaar: just double checked your SG event first log and this sounds strange:
I would expect a sg2jira url here? |
It is actually, the *** is the shadowed/redacted URL of our DO droplet. |
Oh and thanks for taking some time to poke at this, I was getting a bit desperate :) |
Hmm, there is |
Right, I see now, thanks! I haven't done the original setup so I totally overlooked that. I'm not at work currently I just re-read the docs and I can indeed see the two types of urls:
It is likely the explanation for what I was describing #26 (comment) I will test that first thing tomorrow. Might be worth putting an emphasis about that in the documentation. |
@gplsteph : Confirming that the Shotgun 2 Jira path is working now, we indeed have mis-configured field. The Jira 2 Shotgun path is still busted with same error than reported in #26 (comment) I need to take a look at how the transitions are mapped. Importantly we still need to remove the diff --git a/webapp.py b/webapp.py
index 1634a93..62f2ada 100644
--- a/webapp.py
+++ b/webapp.py
@@ -275,7 +275,7 @@ def run_server(port, settings, keyfile=None, certfile=None):
"""
httpd = Server(
settings,
- ("localhost", port), RequestHandler
+ ("", port), RequestHandler
)
if keyfile and certfile:
# Activate https May I suggest for this to be parameterized please? Is it also possible to put a warning/note in the documentation about the two urls paths, it is easy to overlook and we totally missed it, I did for sure when taking over the setup on our end. Keep you posted on our progresses. |
I have played a little bit more and here is a small report:
|
@KelSolaar @gplsteph : the place I'm working at is looking to use this with Jira Cloud, and tasked me with the installation of this daemon. Should we wait for you all to resolve this, or is there some way that I and a fellow dev can pitch in? From my initial observation, I was hoping that we could just be using API keys from Shotgun & Jira Cloud, and not need to set up dummy users that would cost money to operate for a classic model we're not implementing; I am also interested if the webhook can be HTTPS, or not. Thanks! |
I think we are close to be in a good place, the only really showstopper issue for now on my end is point 5 in my previous comment. I haven't had time to look at that yesterday nor will have today but being able to have the other path working is obviously mandatory, transistions mapping is also very important but we can at least do that manually. The webapp we serve is through HTTPS indeed can see from the logs above. We are starting the webapp with the certificates passed to the --ssl_context /***/certificates/privkey.pem /***/certificates/fullchain.pem --port 443 |
@KelSolaar I can see about checking out the code in your branch & also if you ran into #30 on my initial scan of this code. I'm not a Python guru, but willing to take a stab at it. Edit: forgot to mention #31 |
@gplsteph : I'm trying to address my bullet point n. 5, I have set the verbose level to DEBUG in the bridge settings and when I create a comment on the Jira side I get these log messages:
Our webhook is setup as follows: |
@KelSolaar creating a comment from Jira side is not supported I think. If I remember well, only notes which have been synced from SG can be updated back from Jira to SG. |
Thanks, This is what I assumed when looking at that unit test case: https://github.com/shotgunsoftware/sg-jira-bridge/blob/master/tests/test_syncer.py#L1458 This is quite a major issue because we would expect to be able to answer back from Jira. Idea being that the production people don't have to leave Shotgun and the Devs don't have to leave Jira. |
Makes sense. A bit complicated since on the Jira side there is a unique comment and on the SG side you can have multiple notes and replies. Not sure what the workflow should be here... |
I would maybe inline everything on the Jira end:
It will then come down for people to get used to how the system works. |
Regarding the current codebase, I have things kinda working on my end with https://github.com/unquietwiki/sg-jira-bridge ; however, getting a JIRA_SHOTGUN_TYPE_FIELD issue. Most of the changes I did were automated per #31 ; but had to manually change some arg/karg stuff, since apparently Python3 behaves differently for that. Is there a separate codebase I should be investigating, or anything else to do to follow along with this thread? |
I would not expect to get Python 3 support before it is supported by the DCCs themselves, it would certainly be great but hard to achieve with Maya & co. following. What issue do you have exactly? There are so many changes on your fork that it is hard to understand what is going on. |
@KelSolaar when trying to set this up, I noticed shotgunsoftware/shotgunEvents#68 , which was Python 3 support for that side of things; except it appears to be an incomplete port. After seeing your thread on here regarding how the latest version of this was mostly working, I was curious if making a code update would help; especially since the latest Shotgun API does support it. |
At this stage the bridge works for us, the problem is whether the current functionality is enough for our needs. I unfortunately don't think it is because we need to:
@gplsteph : I will bump the internal support ticket with those elements, thanks for your help here. |
No prob, happy I managed to help!
Le 22 sept. 2019 à 23:38, Thomas Mansencal <[email protected]<mailto:[email protected]>> a écrit :
At this stage the bridge works for us, the problem is whether the current functionality is enough for our needs. I unfortunately don't think it is because we need to:
* Have bi-directional messaging between Shotgun and Jira. The fact both applications do not have the same conversation flow is an issue but it could be worked around as mentioned above, i.e. inlining, but not having the capability to do the back and forth is a showstopper for us.
* Being able to map the statuses between Shotgun and Jira, cf. #29<#29>. Like the previous bullet point, this is mandatory core functionality and not having that is also a showstopper for us.
@gplsteph<https://github.com/gplsteph> : I will bump the internal support ticket with those elements, thanks for your help here.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub<#26?email_source=notifications&email_token=AJLYXRH7C7HENDPGYFMUZDTQK7QVBA5CNFSM4ISY7YE2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD7JPZXY#issuecomment-533920991>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AJLYXRFGXHPWLQ6DYQAI5LLQK7QVBANCNFSM4ISY7YEQ>.
|
@gplsteph @KelSolaar I spent some more time on #31 tonight. Still getting the same API error I had a few days ago (missing Jira field), but the code is getting a better linting score, and I think I discovered some stuff in jira_session & shotgun_session that might be causing the incomplete data syncs. |
Hi, I'm not sure which incomplete data sync you are referring to but as mentioned in #26 (comment), the bridge essentially works, whatever is missing for us is functionality at this stage. Cheers, Thomas |
@KelSolaar there was a bunch of TODO & FIXME items in the session code, and the linter found bad code return practices (I saw some sloppy-looking if/return mixes). The people where I'm at right now don't need this anymore; if you or @gplsteph want to try my branch out, I'll file the release form & help out more as able (I need the practice anyway). Thanks. |
Closing this one as the original issues are solved. |
No description provided.
The text was updated successfully, but these errors were encountered: