I’m trying to integrate a third-party tool with Jira server via REST API.
Currently we have a customized Jira used by our client with a business specific issue types.
Basically all I need is to be able to create an issue of a given type, get response (success/error) and get metadata (list of required and optional fields) for that tool via REST API.
We have a create issue page on WebUI, where user can submit his request.
But the problem is all validation logic is “smashed” between some Javascript code, Behaviours and SIL Programs Manager add-ons, AJS scripts, Jira native fields configuration etc.
So I can’t use “plain” Jira REST API directly because it creates issues without taking in account business rules of a given issue type - e.g. requires fields, one fields can have values depending on another field’s value, an attachment is a required as part of an issue etc.
My question is what is the best way to make an integration with Jira.
I want to be sure if someone will try to create an issue via REST API, the data is consistent according to the issue business rules.
I was thinking to write some "proxy" REST API, which will do the all validation needed and create (or edit) / reject the request.
We've developed a separate Jira plugin which serves some scenarios. So, I can add those API to the plugin.
Or, use Jira REST API endpoints like POST /issue (and PUT /issue/), and I have to define a new screen for it, set all required fields via standard Jira settings, set Cascading fields rules and the standard validator will check if everything is ok out-of-the box?
Sorry, I’m new to Jira and not sure if my current understanding is correct now.
Thanks
Tricky. Best to validate the data in a single place (with one set of code) before calling the create REST API. That way you can also modify the validation logic more easily over time. I think I would probably define a new REST endpoint. ScriptRunner lets you script that nowadays
Related
I'm mid-way through a task to migrate a legacy .NET MVC app to use Single Sign On (SSO) to make integration with a to-be-developed mobile app possible. I'm planning on using Azure AD B2C to facilitate this and based on my researched, I need to use custom policies to achieve the required functionality.
Work on this migration is proceeding very slowly. I'm finding the custom policy XML very clunky to work with. It's going to take quite some time to achieve parity with the existing system given the current velocity. I'm wondering whether it would be wise to sidestep a lot of the migration headaches by using the Microsoft Graph API in place of custom policies.
Take registration for example. It appears common to redirect the user to a SignUp.xml custom policy (or the integrated SignUpOrSignIn.xml) to handle adding the user record in the AD B2C data store. Part of this policy would involve calling a REST API to create a corresponding record for this user in the app's database (stores email settings and such). Instead of using these custom policies, my plan would be to instead take the existing registration process and simply add a step which creates the user record on the B2C side using the Microsoft Graph API.
It appears like most things I need may be achieved using the Microsoft Graph API. Things I'd need that I can see are not available are:
logging in to a user account and;
sending verification emails
Are there any other common authentication-related tasks I'm likely to need that couldn't be achieved using the Graph API?
As far as downsides, the fact I'd be handling user passwords (even if it was just to create the user and nothing else) is an obvious concern, but perhaps acceptable. The main thing I'm after is a simple SSO solution that generates secure access tokens (incl. handling reset tokens, etc). I hope then, that this could be a feasible option.
You will miss out on password reset, profile edit, SSO and token expiration etc.
A better way may be to use the base custom policies and achieve a lot of what you need by having the policy call REST API's.
What is your use case?
So I have an application that I want to be able to read from BigQuery and perform queries, be able to read from GSheets to form these queries and upload this data into a directory in Google Drive.
I understand how to individually do these things, but for the sake of consolidating my system, I would like to use one set of credentials for everything. Is this a good way to go about building my system? I would like to follow the "least access possible" guideline to limit visibility to the database.
Is the best way to go about this creating multiple credentials? Should I use OAuth Credentials and include relevant scopes? Or can I create one set of credentials for all of this?
I'm using python for the backend, don't think that's relevant to the question though.
The proper way to handle this is to create the project using the Google API Console and authorize all the APIs needed for this project.
Afterwards, you will have to select the APIs needed by following the steps from this article here.
In order to retrieve the credentials for the project, you will have to select the project you created and based on the type of application you plan on developing, you will have to select the type of credentials needed.
Selecting APIs & Service
Selecting Credentials
Then based on your choice, you will end up retrieving the credentials and use them in your application.
Reference
Authorize Requests.
I am working on developing an integration with Workday. Under my initial analysis, I found that Workday provides multiple wsdls for different modules like "Human resource", "Inventory" etc. I can see this complete list at https://community.workday.com/sites/default/files/file-hosting/productionapi/operations/index.html
I am trying to understand how I get get this list progamatically in my integration so that my user can select one of the wsdls rather than typing in the full name of WSDL. Please share your thoughts on this.
You can programatically retrieve a list of all web service operations by creating a Custom Report based on the "Public Web Services" data source. The report can then be exposed as a RESTful WS for easy retrieval.
Some fields you can include in the report are: Web service, supported operations, api version, endpoint url, WSDL url, etc, etc.
This is highly customisable, in the sense that you can query the RESTful WS Report for specific versions, specific operations, etc, via Prompts / URL Params.
The report-as-a-service, supports also a variety of output formats as well as its own WSDL.
The purpose of a SOAP WSDL is to generate a client stub, i.e. a model that lets your client interact with objects exposed or consumed by the service provider. You don't interact with a WSDL at runtime - you interact with the stub. If you want to make multiple services available, you have to include each WSDL in your client application at compile time and generate their stubs. The services in a given API version do not change, so there isn't a reason to do this dynamically.
To add to the query asked, what we are trying to understand is that whether there an API call/request which we could hit to get the list of web services available to populate it on the UI to select from it.
For Example: In this link, https://community.workday.com/sites/default/files/file-hosting/productionapi/index.html, we have Absence_Management, Academic_Advising, Academic_Foundation and so on and Now, if I want it to be displayed to the end user so that He can select the webservice to be used and accordingly we could download the WSDL as to work on it.
I implemented a simple API.ai bot and I wanted to add it to google home platform but I really need help for the linking account part.
I don't understand if I need to implement an oauth2 protocol for my service or not. Is there any exemple or framework that allow implement this linking account step (any language is ok, it's just for a simple POC).
My goal is to ask my bot some informations and send him some orders to achieve simple processing on a server.
Hope that someone can help me, add a simple bot to google home to access and modify some informations in a server isn't really easy for me ^^
As #Leon noted, you will need to implement the OAuth2 server yourself. The Actions on Google documentation give details about what they are expecting and what steps you can do to implement it yourself. The Authorization Code flow is slightly preferred (additional features from the Assistant will require it in the future), but you're also allowed to use the https://developers.google.com/actions/identity/oauth2-implicit-flow if you wish since it is slightly easier.
There are several packages that are out there that allow you to provide OAuth2, but require you to build the connection to your own account database. I've seen packages for .NET and JavaScript, but it shouldn't be too difficult to find one that meets your needs or to write one yourself.
If you need to authenticate the user, then you will need your own OAuth server. How to hook that up to an action is described in the docs: https://developers.google.com/actions/develop/identity/account-linking
If however, this is just a personal project and you want to test it on your own device, then account linking is not necessary for you to get the action to work. You simply need to hook up your server logic to the action fulfillment. We recommend that you use the API.AI Actions integration. The docs cover how to do that: https://developers.google.com/actions/develop/apiai/dialogs-and-fulfillment
Can I use the REST API to filter out users who have not signed in during the last three months?
(I have admin access if that is needed).
Someone correct me if I'm wrong, but from what I know it's not available out of the box. You would probably need to implement a REST plugin module which would get this data from database (or find an existing plugin that does this - I haven't).
There's a page on Atlassian's Confluence that gives you SQLs to get the last login timestamp for a user (and it seems quite up-to-date): https://confluence.atlassian.com/display/JIRAKB/Retrieve+last+login+dates+for+users+from+the+database
Please note that you would have to think about security when developing such a plugin. I have not really considered this, but there might be reasons to include permission restrictions for such a REST resource.
EDIT: I might have found an API (not REST) that exposes login information without the need to query the database (untested): https://developer.atlassian.com/static/javadoc/jira/reference/com/atlassian/jira/bc/security/login/LoginInfo.html
Unfortunately, the JIRA REST API doesn't provide this resource. The latest supported methods can be found on the JIRA REST API Reference Page.
These methods can be tested on your current installation using the JIRA REST API Browser.
The links above contain all of the info you need on the REST API. If you're still interested in using REST, you can always create your own method for retrieving the user list.
Of course, you could use other methods, like SQL, for example. There are a number of plugins available here.