IBM Watson Discovery API query - ibm-cloud

I am trying to use watson discovery api and makes request like this:
https://gateway.watsonplatform.net/discovery/api/v1
/environments/6da44f3d-678f-476a-ae8b-cf69327fcf93
/collections/f9c98c9e-be05-4a00-bc93-7159f5441251/query
?version=2016-11-07
&query=text:Ukraine,taxonomy:(label:technology,score>0.8)
&count=10
&offset=
&aggregation=
&filter=
&return=
First item in response has taxonomy like this:
"taxonomy": [
{
"score": "0.976715",
"label": "/law, govt and politics/armed forces/army"
},
{
"confident": "no",
"score": "0.499065",
"label": "/technology and computing/computer certification"
},
{
"confident": "no",
"score": "0.496026",
"label": "/law, govt and politics/legal issues/human rights"
}
]`
Taxonomy's item labeled "technology" has score 0.499065 but I need items which has label with word "technology" AND score >0.8 (not OR).
How do I change my request to get what I want? Thanks.

Lets step back first. The goal of this query is to find documets where the text references 'Ukraine' and then filter all results so that they taxonomy technology is there and has a score over 0.8
I can't test this myself without access to your environment but it should be
https://gateway.watsonplatform.net/discovery/api/v1
/environments/6da44f3d-678f-476a-ae8b-cf69327fcf93
/collections/f9c98c9e-be05-4a00-bc93-7159f5441251/query
?version=2016-11-07
&query=text:Ukraine
&count=10
&offset=
&aggregation=
&filter=taxonomy:(label:technology,score>0.8)
&return=

Related

Strapi API Rest V 3.6.8 how to search posts by title?

I have installed version 3.6.8 of Strapi
In the docs for v3.x
https://strapi.gitee.io/documentation/v3.x/content-api/parameters.html#filter
Filters are used as a suffix of a field name:
No suffix or eq: Equals
ne: Not equals
lt: Less than
gt: Greater than
lte: Less than or equal to
gte: Greater than or equal to
in: Included in an array of values
nin: Isn't included in an array of values
contains: Contains
ncontains: Doesn't contain
containss: Contains case sensitive
ncontainss: Doesn't contain case sensitive
null: Is null/Is not null
And I can see those examples
GET /restaurants?_where[price_gte]=3
GET /restaurants?id_in=3&id_in=6&id_in=8
etc..
So I tried
/posts?_where[title_contains]=foo
/posts?title_contains=foo
And I also tried the "new way" in V4
/posts?filters[title][contains]=foo
But all of this attempts return all the post, exactly the same than just doing
/posts?
Any idea how to filter by post title and/or post body?
Almost there my friend! The issue you are facing called deep filtering (please follow the link for documentation).
In Short: the title field is located inside the attributes object for each item
Your items may look something similar to this:
{
"data": [
{
"id": 1,
"attributes": {
"title": "Restaurant A",
"description": "Restaurant A's description"
},
"meta": {
"availableLocales": []
}
},
{
"id": 2,
"attributes": {
"title": "Restaurant B",
"description": "Restaurant B's description"
},
"meta": {
"availableLocales": []
}
},
]
}
And therefor the filter should be
/api/posts?filters[attributes][title][$contains]=Restaurant
Also note:
the $ sign that should be included for your operator (in our case contains)
the api prefix you should use before the plural api id (e.g. posts, users, etc.)
you may prefer using $containsi operator in order to ignore upper and lower case letters (better for searching operations)
Let me know if it worked for you!

How to make child-card Discussion notes rollup to parent card?

How to make child-card Discussion notes rollup to parent card in Azure DevOps?
The way we use ADO is like this:
User Story -> Task 1
-> Task 2
-> Task 3
Both User Story cards and Task cards contain Discussion fields, and we have hit a quandary as to "which cards' discussion fields should we use to enter ongoing notes and discussions"? The Parent (user story)? Or the child (task)? It makes more sense for devs to enter discussion notes in the tasks, but our Support people and managers like to just look at the parent User Story card where they hope to see all discussion notes.
For now I am double-entering discussion notes in both tasks and their parent user story cards, which is not only an inefficient pain, but also violates DRY.
Then it occurred to me that the ideal solution would be for user story cards to be able to display (within the Discussion section) all discussion notes from all child cards. So if I enter a note in a Task (child) card and save it, automatically it would appear as a discussion note within its parent user story card. Ideally I could still enter user-story-specific discussion notes on occasion, but all child cards' notes would be automatically pulled in and displayed (maybe readonly? editable only in the child?) in the parent card, in all cases.
Is there an easy way to make this happen?
If the answer to #1 above is no, then is there a difficult way to make it happen? Maybe via customizations or custom API calls? What would be the best way to achieve my desired result?
This is not possible out of the box in Azure DevOps (at least not to my knowledge).
However I can think of a few ways to get this done, but it requires some custom scripting, and have some drawbacks that may of may not affect your use case.
Option 1. Create a custom extension that aggregates the comments on the parent
This option gives you complete freedom of how to visually design the feature. It is also completely DRY
You can develop your own custom extension for Azure DevOps and create a dynamic section on the User Story card that pulls in the comments from all tasks.
Option 2. Setup a Web Hook for the event "Workitem commented on"
This option does is not completely DRY, but it will at least automate the copying of comments across work items.
By configuring a web hook in Azure Devops to post a json object containing information about the new comment to a REST endpoint of your choice. The payload posted looks like below.
{
"subscriptionId": "5be97cbc-ee4b-4c21-91ea-866a61d624c4",
"notificationId": 4,
"id": "fb2617ed-60df-4518-81fa-749faa6c5cd6",
"eventType": "workitem.commented",
"publisherId": "tfs",
"message": {
"markdown": "[Bug #5](http://fabrikam-fiber-inc.visualstudio.com/web/wi.aspx?pcguid=74e918bf-3376-436d-bd20-8e8c1287f465&id=5) (Some great new idea!) commented on by Jamal Hartnett."
},
"detailedMessage": {
"markdown": "[Bug #5](http://fabrikam-fiber-inc.visualstudio.com/web/wi.aspx?pcguid=74e918bf-3376-436d-bd20-8e8c1287f465&id=5) (Some great new idea!) commented on by Jamal Hartnett.\r\nThis is a great new idea"
},
"resource": {
"id": 5,
"rev": 4,
"fields": {
"System.AreaPath": "FabrikamCloud",
"System.TeamProject": "FabrikamCloud",
"System.IterationPath": "FabrikamCloud\\Release 1\\Sprint 1",
"System.WorkItemType": "Bug",
"System.State": "New",
"System.Reason": "New defect reported",
"System.CreatedDate": "2014-07-15T17:42:44.663Z",
"System.CreatedBy": {
"displayName": "Jamal Hartnett",
"url": "https://vssps.dev.azure.com/fabrikam/_apis/Identities/e5a5f7f8-6507-4c34-b397-6c4818e002f4",
"_links": {
"avatar": {
"href": "https://dev.azure.com/mseng/_apis/GraphProfile/MemberAvatars/aad.YTkzODFkODYtNTYxYS03ZDdiLWJjM2QtZDUzMjllMjM5OTAz"
}
},
"id": "e5a5f7f8-6507-4c34-b397-6c4818e002f4",
"uniqueName": "Jamal Hartnett",
"imageUrl": "https://dev.azure.com/fabrikam/_api/_common/identityImage?id=e5a5f7f8-6507-4c34-b397-6c4818e002f4",
"descriptor": "ukn.VXkweExUVXRNakV0TWpFME5qYzNNekE0TlMwNU1ETXpOak15T0RVdE56RTVNelEwTnpBM0xURXpPRGswTlRN"
},
"System.ChangedDate": "2014-07-15T17:42:44.663Z",
"System.ChangedBy": {
"displayName": "Jamal Hartnett",
"url": "https://vssps.dev.azure.com/fabrikam/_apis/Identities/e5a5f7f8-6507-4c34-b397-6c4818e002f4",
"_links": {
"avatar": {
"href": "https://dev.azure.com/mseng/_apis/GraphProfile/MemberAvatars/aad.YTkzODFkODYtNTYxYS03ZDdiLWJjM2QtZDUzMjllMjM5OTAz"
}
},
"id": "e5a5f7f8-6507-4c34-b397-6c4818e002f4",
"uniqueName": "Jamal Hartnett",
"imageUrl": "https://dev.azure.com/fabrikam/_api/_common/identityImage?id=e5a5f7f8-6507-4c34-b397-6c4818e002f4",
"descriptor": "ukn.VXkweExUVXRNakV0TWpFME5qYzNNekE0TlMwNU1ETXpOak15T0RVdE56RTVNelEwTnpBM0xURXpPRGswTlRN"
},
"System.Title": "Some great new idea!",
"System.Parent": 26
"Microsoft.VSTS.Common.Severity": "3 - Medium",
"WEF_EB329F44FE5F4A94ACB1DA153FDF38BA_Kanban.Column": "New",
"System.History": "This is a great new idea"
},
"_links": {
"self": {
"href": "http://fabrikam-fiber-inc.visualstudio.com/DefaultCollection/_apis/wit/workItems/5"
},
"workItemUpdates": {
"href": "http://fabrikam-fiber-inc.visualstudio.com/DefaultCollection/_apis/wit/workItems/5/updates"
},
"workItemRevisions": {
"href": "http://fabrikam-fiber-inc.visualstudio.com/DefaultCollection/_apis/wit/workItems/5/revisions"
},
"workItemType": {
"href": "http://fabrikam-fiber-inc.visualstudio.com/DefaultCollection/_apis/wit/ea830882-2a3c-4095-a53f-972f9a376f6e/workItemTypes/Bug"
},
"fields": {
"href": "http://fabrikam-fiber-inc.visualstudio.com/DefaultCollection/_apis/wit/fields"
}
},
"url": "http://fabrikam-fiber-inc.visualstudio.com/DefaultCollection/_apis/wit/workItems/5"
},
"resourceVersion": "1.0",
"resourceContainers": {
"collection": {
"id": "c12d0eb8-e382-443b-9f9c-c52cba5014c2"
},
"account": {
"id": "f844ec47-a9db-4511-8281-8b63f4eaf94e"
},
"project": {
"id": "be9b3917-87e6-42a4-a549-2bc06a7a878f"
}
},
"createdDate": "2022-07-03T12:30:03.0691717Z"
}
In particular you have the comment message under message, the author of the message under fields.System.ChangedBy, the date of the comment in fields.System.ChangedDate and the parent workitem id in System.Parent
Using this information your REST service that receives the json object can create a comment on the parent work item using the Comments Rest API or post an update to the workitem where you set the System.History field to the value of the comment. This also allows you to set the original comment time and author, given that the user account you use in your automation has the permission Bypass rules on work item updates granted.
Drawbacks
If tasks can be moved from one user story to another, then the task comments on the user stories need to be moved. The same idea as above can be applied to solve this. By configuring a webhook for WorkItem updated you can listen for all updates to tasks.
By fetching the previous revision (Revision is found in resource.rev) from the Revision Rest API and comparing the field System.Parent you can determine whether the task has been moved or not and add the comments to the new parent and remove them from the old.
Similarly if you want to propagate comment updates and reactions, you would need to extend the webhook functionality even further.

What is OData standard for odata.nextLink in case of 1:N $expand queries?

We can see the odata.nextlink standard in the server driven paging for normal queries here. But there is no odata.nextlink standard mentioned in case of 1:N $expand queries in $expand docs.
Can someone please confirm OData standard for 1:N $expand queries please?
Example:
If we have multiple account_tasks for a single account, how the result should look like:
GET [Organization URI]/api/data/v9.1/accounts?$top=1&$expand=Account_Tasks($select=subject)
Option-1: Where data is shown in list inline till the page-size, and odata.nextLink is shown if data count exceeds the page-size. So, odata.nextLink will show the next set of results. (Similar to standard pagination here.)
{
"#odata.context": "[Organization URI]/api/data/v9.1/$metadata#accounts(name,Account_Tasks(subject,scheduledstart))",
"value": [
{
"#odata.etag": "W/\"37867294\"",
"name": "Contoso, Ltd. (sample)",
"accountid": "7a4814f9-b0b8-ea11-a812-000d3a122b89",
"Account_Tasks": [
{
"#odata.etag": "W/\"28876919\"",
"subject": "Task 1 for Contoso, Ltd.",
},
{
// More account_tasks here. No odata.nextLink if data count < page-size.
]
}
]
}
Option-2: We'll show empty results inline and provide an odata.nextLink to actual data.
{
"#odata.context": "[Organization URI]/api/data/v9.1/$metadata#accounts(name,Account_Tasks(subject,scheduledstart))",
"value": [
{
"#odata.etag": "W/\"37867294\"",
"name": "Contoso, Ltd. (sample)",
"accountid": "7a4814f9-b0b8-ea11-a812-000d3a122b89",
"Account_Tasks": [],
// Empty list shown above and URL given below will show the full results.
"Account_Tasks#odata.nextLink": "[Organization URI]/api/data/v9.1/accounts(7a4814f9-b0b8-ea11-a812-000d3a122b89)/Account_Tasks?$select=subject,scheduledstart"
}
]
}
Option-3: Where data is shown in list till page-size, and odata.nextLink is shown every time (even if data count is smaller than the page-size). So, the odata.nextLink will show the full expand results including inline results.
{
"#odata.context": "[Organization URI]/api/data/v9.1/$metadata#accounts(name,Account_Tasks(subject,scheduledstart))",
"value": [
{
"#odata.etag": "W/\"37867294\"",
"name": "Contoso, Ltd. (sample)",
"accountid": "7a4814f9-b0b8-ea11-a812-000d3a122b89",
"Account_Tasks": [
{
"#odata.etag": "W/\"28876919\"",
"subject": "Task 1 for Contoso, Ltd.",
},
{
// More account tasks here
],
"Account_Tasks#odata.nextLink": "[Organization URI]/api/data/v9.1/accounts(7a4814f9-b0b8-ea11-a812-000d3a122b89)/Account_Tasks?$select=subject,scheduledstart"
}
]
}
Thanks in advance.
Good question -- paging of nested results is often misunderstood.
Nested results are paged individually, so where the nested account_tasks for a particular account exceeds a sever-defined threshold, the account_tasks up to that threshold are included, along with a nextlink to retrieve the additional account_tasks for that account. Which, I believe, is your Option 1.
Note that, since the threshold is server-defined, it is also valid to have a threshold of 0, and only include a nextlink for the nested account_tasks. However, each account will still have a different nextlink, and following that nextlink will return only those account_tasks for the account in which the nextlink was returned.
Does that make sense?

MS Graph REST API checkout user

I've managed to successfully checkout a file using the https://graph.microsoft.com/beta/drives/{driveId}/items/{itemId}/checkout
Now, I'd like to get the information about the user, who actually perform the checkout operation.
It's possible to check if the item is locked:
https://graph.microsoft.com/beta/drives/{driveId}/items/{itemId}?select=*,publication
However, according to DOCs, publication doesn't provide information about the checked user. Without information who locked the file is the whole checkin/checkout logic is useless.
This kind of information could be retrieved via the metadata for an item in a list as demonstrated below:
https://graph.microsoft.com/beta/sites/{site-id}/lists/{list-id}/items/{item-id}?expand=fields(select=CheckoutUserLookupId)
Once you get checkout user id (CheckoutUserLookupId field) , user details could be determined via the following endpoint:
https://graph.microsoft.com/v1.0/sites/{site-id}/lists('User Information List')/items/{CheckoutUserLookupId}
where CheckoutUserLookupId is the user id from the previous request
https://graph.microsoft.com/beta/sites/{site-id}/lists/{list-id}/items/{item-id} can't work with folders.
Anyway, drive endpoint "Allows access to the list as a drive" (according to MS Graph Docs). It works with folders as expected.
So I have
get the drive-id: /sites/${siteId}/drives
list root folder: /drives/{drive-id}/items/root/children?select=name,publication
if an item is locked, it's possible to list the activity on the item:
/drives/${idObj.driveId}/items/${idObj.fileId}?select=id&expand=activities
return list of actions:
"activities": [
{
"#odata.type": "#oneDrive.activityEntity",
"#odata.id": "https://xxxxxxxxxx/v2.0/oneDrive.activityEntity2a3649d6-2xxxxx",
"#odata.editLink": "oneDrive.activityEntity2a3649d6xxxxxx",
"#sharePoint.localizedRelativeTime": "0|July 30",
"action": {
"checkout": {}
},
"actor": {
"user": {
"email": "XXX#XXX",
"displayName": "vladimir",
"self": {},
"userPrincipalName": "XXX#XXX
}
},
"id": "XXXXXXXXXXXXXX",
"times": {
"recordedTime": "2018-07-31T04:59:03Z"
}
},
although no user ID at least a have the email....

How to get TFS(Team Foundation Server) work items(bug,task) details using REST api?

I have been working on TFS REST api, to get the work items(bug,task) details.
I have used GET method,
GET https://shankarsam.visualstudio.com/DefaultCollection/New-1/_apis/wit/queries/Shared%20Queries/My%20Bugs?$depth=1&api-version=2.2
It shows the following output
"id": "e7731d7b-10d2-441f-899f-b081e4008b21",
"name": "My Bugs",
"path": "Shared Queries/My Bugs",
"createdBy":
{
"id": "7bb24a89-a490-4ffa-9047-252e4a2b274b",
"displayName": "kalaisankaran B "
},
"createdDate": "2016-07-15T05:30:18.34Z",
"lastModifiedBy":
{
"id": "7bb24a89-a490-4ffa-9047-252e4a2b274b",
"displayName": "kalaisankaran B "
},
"lastModifiedDate": "2016-07-15T05:30:18.34Z",
"isPublic": true,
I couldn't get all bug details.
In case of UI, I have navigated to Shared Queries -> My Bugs -> Bugs has been listed. Please see the attached screen shot.
The best place to start with this is to look at the REST API Documentation. It covers this exact scenario with some useful examples.
I see that you have retrieved the query hierarchy, and with that you can run a query and then get the work items.
From your call above, I will use the "My Bugs" query as the example.
GET https://shankarsam.visualstudio.com/DefaultCollection/New-1/_apis/wit/wiql/7731d7b-10d2-441f-899f-b081e4008b21
Which will return query results:
{
"queryType": "flat",
"workItems": [
{
"id": 300,
"url": "https://fabrikam-fiber-inc.visualstudio.com/DefaultCollection/_apis/wit/workItems/300"
}
]
}
From that, you can use the id property in the result to get the work item:
GET https://shankarsam.visualstudio.com/DefaultCollection/New-1/_apis/wit/workItems/1
Which will return the work item.
I got the solution. If we need to display all the Bugs or Tasks which is associated in the project. Use the following rest api call.
POST https://<Account Name>.visualstudio.com/DefaultCollection/<Project Name>/_apis/wit/wiql?api-version=1.0
Ex :
POST https://shankarsam.visualstudio.com/DefaultCollection/New-1/_apis/wit/wiql?api-version=1.0
Header :
Content-Type application/json
Request Body Ex :
{
"query": "Select [System.Id], [System.Title], [System.State] From WorkItems Where [System.WorkItemType] = 'Bug'"
}
Need to display Task item means , try this [System.WorkItemType] = 'Task'
Display Bug or Task related work items, Repo's try this :
GET https://<Account Name>.visualstudio.com/DefaultCollection/_apis/wit/workitems?id=<Issue ID>&$expand=all&api-version=1.0
Ex:
GET https://shankarsam.visualstudio.com/DefaultCollection/_apis/wit/workitems?id=23&$expand=all&api-version=1.0