I'm able to retrieve tasks for a workspace assigned to a particular assignee - using curl:
curl -u <api_key>: "https://app.asana.com/api/1.0/tasks?workspace=14916&assignee=me"
However I'd like to be able to search for not just "me" or an id of a user - but "Nobody" as you are able to do in the web interface.
curl -u <api_key>: "https://app.asana.com/api/1.0/tasks?workspace=14916&assignee=Nobody"
Results in an error returned by the server:
assignee: Not an email, ID, or "me": Nobody
Is there an id for "Nobody" that I can use here?
This is currently not supported. We're working on designing a way to expose the power of the Advanced Search in the API, but it's still early in the design phase. We have internal integrations that (for instance) look at a project and find all the unassigned incomplete tasks, but the way we do it is to get all the incomplete tasks (?completed_since=now) and then filter out the ones with assignees on the client. That's obviously not what we'd like to be doing, and there's no way to do it for an entire workspace.
So all I can say it that it's high on our list of API priorities to support this, but we don't yet. Sorry :-(
Related
I am trying to collect all active TIs via the Beta Graph API by following this. But it doesn't return anything. Here is what I use in Postman:
https://graph.microsoft.com/beta/security/tiIndicators
Response (200):
{
"#odata.context": "https://graph.microsoft.com/beta/$metadata#security/tiIndicators",
"value": []
}
A bit of context for the environment I work in.
The tenant has multiple Sentinel workspaces & resource groups.
The application I use has the correct permissions:
ThreatIndicators.Read.All
ThreatIndicators.ReadWrite.OwnedBy
ThreatSubmission.Read.All
ThreatSubmission.ReadWrite.All
It is my current belief that this might be due to the limitations of the Beta API. My reasoning is that accourding to this documentation you need the ThreatIndicators.ReadWrite.OwnedBy permission to access the API. This would suggest that currently you can only view TI's that the resource itself created.
If more info is needed just ask.
According to the documentation, ThreatIndicators.ReadWrite.OwnedBy permission allow you to manage threat indicators your app creates or owns.
If you want to read all the threat indicators for your organization then your app needs ThreatIndicators.Read.All permission.
Although this is not a solution to the question it is a workaround. By using the Log Analytics API you can get the TI via a KQL.
ThreatIntelligenceIndicator
| where ExpirationDateTime > now() and
NetworkIP matches regex #"^(?:(?:25[0-5]|(?:2[0-4]|1\d|[1-9]|)\d)\.?\b){4}$" and
ConfidenceScore > 25
| summarize by NetworkIP
This is probably better as you can also use a watchlist to exclude specific IP addresses with one request.
One thing I struggled with this was Authorization. You must give your Application permission to use the api.loganalytics.io API, and the application needs the Log Analytics Reader role in the Log Analytic workspace you want to use.
I am in the process of switching the LDAP backend that we use to authenticate access to Gerrit.
When a user logs in via LDAP, a local account is created within Gerrit. We are running version 2.15 of Gerrit, and therefore our local user accounts have migrated from the SQL DB into NoteDB.
The changes in our infrastructure, mean that once the LDAP backend has been switched, user logins will appear to Gerrit as new users and therefore a new local account will be generated. As a result we will need perform a number of administrative tasks to the existing local accounts before and after migration.
The REST API exposes some of the functionality that we need, however two key elements appear to be missing:
There appears to be no way to retrieve a list of all local accounts through the API (such that I could then iterate through to perform the administrative tasks I need to complete). The /accounts/ endpoint insists on a query filter being specified, which does not appear to include a way to simply specify 'all' or '*'. Instead I am having to try and think of a search filter that will reliably return all accounts - I haven't succeeded yet.
There appears to be no way to delete an account. Once the migration is complete, I need to remove the old accounts, but nothing is documented for the API or any other method to remove old accounts.
Has anybody found a solution to either of these tasks that they could share?
I came to the conclusion that the answers to my questions were:
('/a/' in the below examples is accessing the administrative endpoint and so basic Auth is required and the user having appropriate permissions)
Retrieving all accounts
There is no way to do this in a single query, however combining the results of:
GET /a/accounts?q=is:active&n=<number larger than the number of users>
GET /a/accounts?q=is:inactive&n=<number larger than the number of users>
will give effectively the same thing.
Deleting an account
Seems that this simply is not supported. The only option appears to be to set an account inactive:
DELETE /a/accounts/<account_id>/active
I am writting a custom slack command that implements a
task manager like interface (I know ... there are many out there :-), mine interfaces with odesk/upwork to outsource my micro-tasks :-) ) .
Anyway, I like a lot how the /remind command included Complete Delete etc links in its output to facilitate subsequent interactions with the user that entered the command and I am trying to figure out how to do the same trick.
What I have thought so far is to include links in my output that are ... GET /slack-link?method=POST&token=xxx&team_id=xx&command=.. ie carry in their query string the complete json payload that slack would have produced from a normal custom command. slack-link acts as a "proxy" whose sole role is to submit a POST back to my normal slack endpoint. I can even reuse the same response_url for these command-links.
I have not tried it but I think these URLs will just open another window so that path wont exactly work...
Has anybody tried something like that before?
As you've learned, those are currently only available to built-in commands. However, as I was curious and wanted to know how those are done, I looked in the API and found out that the URLs are just formatted normally but have a special "protocol":
You asked me to remind you to “test”.
_<slack-action://BSLACKBOT/reminders/complete/D01234567/1234//0/0/5678|Mark as complete>
or remind me later: <slack-action://BSLACKBOT/reminders/snooze/D01234567/1234//0/0/5678/15|15 mins> [...]
Clicking on such a link results in an API request to method chat.action, with the following parameters:
bot: BSLACKBOT
payload: reminders/complete/D01234567/1234//0/0/5678
token: xoxs-tokenhere-nowayiampostingithere
So it looks like those URLs have three parts:
<slack-action://BSLACKBOT/reminders/complete/[...]|Mark as complete>
slack-action://: the "protocol" like prefix to let Slack know this is a chat action URL.
BSLACKBOT: the bot which (who?) will receive the payload. Can only be a bot user and the ID must start with B, or the API request will fail with invalid_bot.
the rest of the URL: the payload that gets passed to the bot. It doesn't look like this is parsed nor handled specially by Slack.
This is actually not a new feature, since they used to have API URLs back in late 2013 or early 2014 (I don't remember precisely) which they removed for "security reasons".
It could be interesting to see if we can use chat actions with custom bots, and if so, what we could do with it.
I got the answer from Slack support:
In regard to your original question: currently Slack doesn't provide
the ability to embed 'action' links in our custom integrations. Only
built-in features like /remind can utilize these at the moment. For
external services, you'll need to link to a URL that opens in an
external web browser.
We do hope to provide a similar function for custom integrations in
the future, allowing for interactive messages.
Thanks,
Ben
When I make API calls to the server, I'm getting 404 errors for various data -- grades, role IDs, terms -- that I won't get on the next time I call it. The data's there on the server, viewable by the same user, and is often returned successfully, but not every time. The same user context will return data successfully for other calls.
Any ideas what could be causing this?
I'm using the Valence API with the Python client library and our 9.4.1 SP18 instance of Desire2Learn in a non-interactive script.
more detail: the text it returns on the bad 404s is " ErrorThe system cannot find the path specified."
It would help enormously to gather data about your case: packet traces that can show successful calls from your client alongside unsuccessful calls, in particular, would be very useful to see. If you are quite certain (and I see no reason you shouldn't be from your description) that you're forming the calls in the right way each time you make them, then the kind of behaviour you're noticing would seem to speak to some wider network or configuration issue: sometimes your calls are properly getting through the web service layer, and sometimes they are not -- this would seem therefore not to be down to the way you're using the API but in the way the service is able to receive that request.
I would encourage you, especially if you can gather data to provide showing this behaviour, to open a support incident with Desire2Learn's help desk in conjunction with your Approved Support Contact, or your Partner Manager (depending on whether you're a D2L client or a D2L partner).
I'm working on the most basic Valence use just to prove it works -- using php to run a "whoami" query.
I authenticate fine, get the userId, userKey, and userSig back. I set these in the userContext object. The call to createAuthenticatedUri seems to work well -- all parameters are in the GET url I would expect to see.
I've also verified that the command path (/d2l/api/lp/1.0/users/whoami/) is valid, from another developer who is connecting to a a completely different server.
However, when I try to make the request, D2L tells me "404 Page not found".
I can make a call to /d2l/api/versions/ and that returns just fine.
Anyone have any suggestions?
Thanks in advance.
Please note that your path /d2l/api/lp/1.0/users/whoami/ is not valid: the proper route for the whoami API call is /d2l/api/lp/{ver}/users/whoami without the trailing slash, and with the right version number filled in to target the API contract you want to target among those offered by the LMS -- in your case, that might be /d2l/api/lp/1.0/users/whoami, but it's also likely that you have more modern API contracts available on your LMS as well, which you can determine using the call to retrieve the LMS' version table.