I am trying close all the JIRA tickets on post-receive hook. My python script is executing on post-receive, from commit message I am able to get JIRA ticket number and found the ticket in JIRA also.
All it is working fine but when I want to change status of JIRA ticket with below code getting error 400 bad request response from JIRA server.
jira.transition(issue,'31')
also tried giving 500 internal server error.
jira.transition_issue(issue, '5', assignee={'name': 'pm_user'}, resolution={'id': '3'})
Please help me how to change the status of the ticket.
Authentication with JIRA and finding ticket with
issue = jira.issue(issuekey)
is also successful but unable to change the ticket status to "Done".
"500 internal server error" means an error on the server side, and your Jira admin can give you some clues by fetching the error message.
Check this thread to see if the solution applies:
Here's the python solution, which is what I'm working with. The transition IDs are part of the Workflow view, but not everyone can see those IDs. In my case I can see the graph but JIRA doesn't actually display what the IDs are in order to make it work.
You'll note that for the start of each section is an id and a number. Those are the numbers that you need and they CAN be different so you'll want to look at an issue in every one of the states and dump out their transitions to see what the ids are.
Related
I spent the last day and a half researching this problem to no avail. I found many similar problems, but none that exactly address my issue. I am attempting to integrate Payflow Pro with transparent redirect, but cannot successfully complete a transaction. I am using the test environment with a test Payflow Gateway account.
I can successfully retrieve a secure token by posting the following from my test server to https://pilot-payflowpro.paypal.com:
PARTNER=[hidden]&VENDOR=[hidden]&USER=[hidden]&PWD=[hidden]&TRXTYPE=S&TENDER=C&CREATESECURETOKEN=Y&SECURETOKENID=20180916085333999&URLMETHOD=POST&SILENTTRAN=TRUE&AMT=2&BILLTOFIRSTNAME=John&BILLTOLASTNAME=Doe&BILLTOADDRESS=123TestDr.&BILLTOCITY=Testcity&BILLTOSTATE=TN&BILLTOZIP=55511&BILLTOEMAIL=johndoe#test.com&USER1=3&USER2=&USER3=0&USER4=2
to which I receive the following response:
RESULT=0&SECURETOKEN=[hidden]&SECURETOKENID=20180916085333999&RESPMSG=Approved
NOTE: I have configured a Return URL using PayPal Manager, which is why RETURNURL is not included in the secure token request. However, I also have tried with RETURNURL specified, and I have obtained the same end result.
I use the results from the secure token request to create a cc collection form. I input test credit card details using acct# 5105105105105100, then post the following from the browser directly to https://pilot-payflowlink.paypal.com:
fund_id=3&ACCT=5105105105105100&CVV2=555&EXPMONTH=01&EXPYEAR=20&EXPDATE=0120&SECURETOKENID=20180916085333581&SECURETOKEN=[hidden]&feeTokenID=20180916085333999&feeToken=[hidden]
The response is properly redirected to the Hosted Page error URL I have specified in my Payflow Manager Service Settings. My problem is that I do not understand why it is redirecting to the error url with the following message:
RESPMSG=Failed to connect to host Input Server Uri = https://pilot-payflowpro.paypal.com:443
NOTE: The value above is only one part of the response sent to the error page. The rest of the return values include information from my original secure token request, which I would assume could only be returned if a successful connection had been established with the link in the error message??
To clearly state the problem:
I have already successfully connected from my test server to the link specified in the error message, when first I obtained the secure token.
The post that results in the error message was sent from the browser (in this case, on the same physical box as my test server) to https://pilot-payflowlink.paypal.com, which is not the URL specified in the error message.
Finally, the error seemingly occurs during the Payflow process - to my understanding, there should not be a call from my server or the browser to the link in the error message at this point during the process. I mention this specifically to address the many search results I found relating this particular error message to PayPal's requirement for TLS1.2, which is already properly configured on my server (I should mention for the sake of completeness, I do still have TLS1.0 enabled on my test server, but cannot disable it for unrelated reasons. Nonetheless, I was able to successfully connect to obtain a secure token, and my server passes PayPal's own TLS test at https://tlstest.paypal.com/).
I should mention that I also have tried to complete this same transaction on our production server, still using test credentials and test endpoints at PayPal, with exactly the same results. The test server is also set up for TLS1.2 with TLS1.0 enabled, and also passes PayPal's test.
This problem may be the one that pushes me full-on into insanity, so any help really would be appreciated!!
Disabling TLS1.0 has helped others with this issue. If you keep having problems, contact PayPal's support
For anyone who might find this question and be similarly frustrated, I want to share that I was able to solve the problem by creating a new Payflow Gateway test account.
I spent a great deal of time on trial and error solutions with no success, and PayPal Merchant Technical Services was able to duplicate the problem but was also unable to find a solution. Finally, after simplifying my test app as much as possible (two bare-bones HTML forms filled in and submitted manually), I came to the conclusion that there might be something wrong with my test account. Upon creating a new account with new credentials, then inserting them back into my original code, everything worked perfectly.
As of this morning, PayPal MTS is continuing to research the problem, since others have reported similar issues.
For others with similar problems, it is worth noting that I am now able to complete transactions while TLS 1.0 remains enabled.
Running on GitHub Enterprise I have a small Jenkins job that looks for pull-request comments and triggers a script depending on the message.
Now I only want to trigger the script if review is already done from GitHub point of view, like all CODE_OWNERS and no additional person requested changes. I don't want to implement that logic myself. GitHub has different section for reviews and status checks. I only want review state, since I am going to set the status myself.
But I was not able to the correct value from the API endpoint. Neither from pull-request itself, nor from pulls/id/reviews.
Closest that i found was "mergeable_state", but this unfortunately takes the status check into consideration.
Is there another place to look for?
I don't think you can fetch the global review status. I think that the best you can do is to check that there are no review requests and fetch all reviews to check if there are no requested changes.
Finally we decided to make a Probot app in Github which was able to get all the required information.
I have 3 related github repos, with associated issue trackers. I'd like to get email when anything happens in the issues, but not whenever someone pushes, or makes a pull request. I don't see the ability to control notifications at this level of granularity.
I know that I can unsubscribe from specific threads, but that doesn't give me what I want either.
Alternatively, if there was a way to tell which type of notification it is in the email, so I can set up a filter, that would be fine too. However, I haven't been able to determine a consistent difference on that front either.
That's not possible currently using the features GitHub offers. However it may be possible using GitHub API.
I'd like to get email when anything happens in the issues, but not whenever someone pushes, or makes a pull request.
All Pull requests are issues but not all issues are Pull requests. That's being said, you cannot [currently] unsubscribe from pull requests and get the issues, since the pull requests are issues.
Since you are developer you can develop your own app to notify you (send you emails) when new issues are opened to specific projects.
Taking IonicaBizau/git-stats as example, you can access the issues like this:
https://api.github.com/repos/ionicabizau/git-stats/issues
You will get 304 Not Modified if there are no new issues. That way you can check if there were added new issues or not. Checking if the issue is pull request is done by checking if there is a pull_request field in the object, like mentioned here.
An alternative that I just found, is the Message-ID field of the email. the pull and merge emails all have <org/repo/pull/....> the issue emails have <org/repo/issue/....> so, I can filter on the Message-ID field.
Regarding this API: https://developers.google.com/admin-sdk/email-audit/#accessing_account_information
I have been using the Admin SDK to retrieve login history for users in our Google Apps for Business setup. When I request individual users at a time, the request sometimes takes a few hours to process (in which the state is PENDING). However, when those few hours pass, I still get the login history that I need.
The problem continues as I begin requesting more users. We have around 750 users, and of those 750~ requests I made, 725 gave me an error after waiting ONE WEEK for my requests to be processed. Even worse, the ones that did not error out are still pending! Here is the response I get when I check the status of a request that errored out:
{'status': 'ERROR', 'adminEmailAddress': '***#etsy.com', 'requestDate': '***', 'requestId': '***', 'userEmailAddress': '***#etsy.com'}
This has got to be the flakiest and most unreliable API I have ever been unfortunate enough to work with. Requests can take anywhere from an hour to over a week to process, with no indicator of success in the mean time. Errors can also happen for no apparent reason, and no messages or explanations as to why.
It looks like this issue has been resolved by the Google Engineers. Try to run the calls again. It shouldn't be in pending more than the "normal" expected time. I just tried earlier, and I was able to export login info for my users.
After paypal updated their interface (sandbox.paypal.com for example is not working, now you have to go to developer.paypal.com) many of the things are not working: 2 of them are particularly frustrating and I was hoping someone here knew how to get around them:
Am I the only one whose sandbox customer test accounts are not able to make purchases? The transaction page says they are not available.
IPN validation is not letting me send a https request. When I do it says there is something wrong with the server name. Yesterday however before the update I could get verified status. If I dont put https, now my handler gives me an invalid responde status, code: 400. What does it mean?
To fix the HTTP 400 error, follow the instructions in https://www.x.com/content/bulletin-ipn-and-pdt-scripts-and-http-1-1 and update your code to pass "Host" information. Ideally, things should work with just the recommended changes from the above link. Apparently, thats not the case. Here is a fix from one of the PayPal MTS person - PalPAL sandbox IPN processor rejecting all messages?
Remove the "cmd=notify-validate" option from the validation URL. I tried this and it worked. Though it doesn't return the right string, atleast it doesnt break with the 400 error.
While we wait for a fix from Paypal, I wonder how a company like PayPal can cause such a huge blunder and not post anything on their status page - https://www.x.com/developers/paypal/documentation-tools/site-status/pp-cri. It just makes you think that even smaller companies can do a better job than companies like PayPal.
For the code:400 issue, you have to update the post to version 1.1. That information is located here.
https://www.x.com/content/bulletin-ipn-and-pdt-scripts-and-http-1-1 in this bulletin.
However, as I posted before the asp.net example uses a call, that does not exist, so I was only able to get mine partly working. After fixing this, the servers appear to be rejecting calls to https, or the cert they have installed is invalid.
Action Required before February 1, 2013
Merchants need to update their IPN and/or PDT scripts to use HTTP 1.1, and include the “Host” header in the IPN postback script. In addition to this bulletin, these merchants will be notified via a direct email.
Alright, seems to be fixed!
If you are having trouble logging in, like suggested above, clear cache and cookies and try again.
Regarding the error 400, seems to have been solved by paypal!