I have Jira Tempo plugin setup for my Jira.
I try to get all users with rest API from the section "Manage Staff". But in the documentation no any example how to do it.
Documentation says I can get all users using http://{JIRA_BASE_URL}/rest/tempo-accounts/1/account but it's not.
I'm just getting JSON where are some 7 ids with keys: Prod, Tech, Internal, Research, Shared, Security, Urgent.
Does anybody know how to get it?
Related
Since the Graph documentation indicates that the publication facet is available in v1.0, I'd like to report that it is not possible to get all checked out files in group/SharePoint sites.
https://learn.microsoft.com/en-us/graph/api/resources/publicationfacet?view=graph-rest-1.0
Use case: our customers would like to know which group files in their Office 365 tenant have been checked out (by who - would be great - for another time).
It's not possible to get this global picture with requests made with Graph API:
GET /v1.0/drives/driveID/root/children?$select=name,publication
Using delegated permissions, I'm only able to see the 'checkout'
value for files I have checked out myself. All other files checked
out by others appear as 'published'.
Using app permissions, I'm only able to see the 'checkout' value for
files checked out by apps, any apps (checkout using Graph API beta).
Here's an image of the various checkout scenarios as seen in SharePoint, and then in our Graph-based app with different authentications (values verified in Postman).
Image link
With the traditional OAuth API, I can specify the ?hd=<domain> parameter to limit logins to specific G Suite domains. I'm unable to find a way to do this with the googleyolo auto sign-in API.
Is this supported or am I just not able to use the API at this time?
I'm the product manager at Google for this library. This is a good feature request and we have it on the roadmap but no timeline yet. I'll update this answer when it's available, but we've got a ton of great feedback and requests from developers around this library so it might be some time to work through the backlog.
We're building a mashup app that allows you to view data and information from multiple sources in one place.
To do this we need to get all conversations in O365 Groups and have been exploring how to build a daemon job.
According to the documentation this should be supported since we have the permissions Group.Read.All and Group.ReadWrite.All.
However it seems like Groups Conversations is an exception to what you can read with an application permission with Microsoft Graph which is mentioned in a small note on the subscriptions page:
We get permissions errors when calling the API with a application permission using a certificate (fetching groups and other data works fine) so this seems to be a limitation.
This also seems to affect fetching threads which doesn't seem to have any notes regarding application permissions at all since we can't fetch those either.
Does anybody know if there is a workaround or if we're doing something wrong here?
(NOTE: This seems to be a related question: Microsoft Graph API : "403 forbidden" error when getting groups conversations but I'd like to have some input from Microsoft on this)
Microsoft confirmed this as being an issue in the Microsoft Graph through our partner programme.
Until fixed by Microsoft this means that there is no good solution except workarounds as of now.
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.
I'm trying to create a redistributable web application that will integrate with Google Analytics through the Google Reporting API. Customer will install the application on their server.
I'm following this tutorial (I'm using PHP, but I believe this is not of importance for my question)
https://developers.google.com/analytics/resources/tutorials/hello-analytics-api
This works fine. No issues there.
However I can't figure out one missing element:
The tutorial starts with sending me to the Google APIs console where I have to create and configure a new API project and create and configure a client ID.
That's a lot of work that requires fairly technical knowledge (redirect url, selecting correct API, error-prone copy-and-pasting, etc.)
So my questions:
Is there an API so I can programmatically set this up for my user?
If that's not possible, is there a more user-friendly way to obtain Analytics reporting that is future-proof? (I noticed they are currently deprecating a few older APIs)
Unfortunately that's AFAIK not possible.
You could go one of the following ways:
Move client_id and client_secret to some configuration file and help your customer with deployment.
Show a one-time setup wizard for your app and guide your customer step-by-step. There you can at least provide him with the right callback URLs.
Regard your application as "installed application" and instrument curl or something similar for sending the requests.