I have some code which gets details of lists in a SharePoint site then later wants to find out if a list with the same name still exists. This works fine except for list names that contain a colon - I find Graph misinterprets the colon and 'corrupts' the URL.
For instance, in Graph Explorer when I give it the following query:
https://graph.microsoft.com/v1.0/sites('mysite.sharepoint.com,aa-aa-aa,bb-bb-bb')/lists('19:abcdef#thread.tacv2_wiki')
The error response contains the following in the 'message' property:
The expression \"sites('mysite.sharepoint.com,aa-aa-aa,bb-bb-bb')/lists('19')/abcdef#thread.tacv2_wiki\" is not valid.
Note that it's split the original URL, thinking the colon is the start of a new segment in the path, even though it's inside a quote.
I've tried all sorts of quoting of the colon (%3A and %253A and %25253A) and different styles of quote characters, but they all either return the same error or give a parsing error.
More information - I specifically want to search by name not by original id (which would be much easier), I'm acutually using Graph Managed API in code but it generates the same error (you'd think it would internally know how to quote), the list is actually a hidden one created in a Teams site to manage channel information.
I was also able to reproduce your issue but as a work around you can use the filter query parameter to get the list by using below query.
https://graph.microsoft.com/v1.0/sites/soaadteam.sharepoint.com,c1178396-d845-46fa-bc0c-453d2951dad5,19ee9a1e-001d-48f1-9ee8-b0adfde54e45/lists?$filter=displayName eq '19:abcdef#thread.tacv2_wiki'
Related
If I navigate to /rest/api/2/issue/createmeta/PROJ/issuetype/N (in this case, I'm getting Task), the list of fields returned is incomplete. There are a number of customfields that are in use (I can see them both in the tickets themselves, and also in /plugins/servlet/project-config/PROJ/fields ) that are in the createmeta data.
I'm really trying to do this in python jira, where I'm using "expand='projects.issuetypes.fields'" in the createmeta() call, but I figured I'd double-check the results in the rest API directly, and I'm getting the same results there, too.
This is happening in jira 8.20.7.
Essentially, what I'm trying to do, is to programatically get a name/id mapping of all fields in the ticket type. I'm having far more difficulty doing that than I thought there would be. I would do it based on /rest/api/2/field but the jira admins have allowed some duplicated names...
EDIT: I realized that it might be worth noting that some of the fields I'm looking for are coming from a ServiceDesk form, although, as far as I can tell, there's no way to determine that, since one of the missing fields contains the name of the form.
Why are you using createmeta endpoint?
Instead of that, in order to get all of the customfields and their values; just note their id and get the values from /rest/api/2/issue/{issueKey} endpoint.
When you send a GET request to /rest/api/2/issue/{issueKey} endpoint, you will get a JSON object which contains "fields" object in it.
And using the "fields" you can determine all of the values that include system fields (description, assignee, etc.) and custom fields (like customfield_<customfieldid>).
And for a general approach, you may want to look at the field types in that response.
I'm having a hard time figuring out how the /me/drive/search endpoint matches documents.
When I try /v1.0/me/drive/search(q='myQuery') I receive documents with the name myQuery back. This makes sense. What doesn't make sense is that if try /v1.0/me/drive/search(q='.') I receive a giant list of results from across my organization. It appears that these documents are accessible to me, but when I try to search for one of them by name they don't come up.
Example
/v1.0/me/drive/search(q='.') returns many documents, one of which is named "My Test Document"
/v1.0/me/drive/search(q='My Test Document') returns no results.
One would expect that the 2nd query returns the same document as the first query.
We've made a change that we believe should help for this specific query. Hopefully you'll get consistent results now!
I'm using Microsoft Graph to get a list of messages for a user.
I'm using the following URL
https://graph.microsoft.com/v1.0/me/mailFolders/inbox/messages
One important thing that is returned by this is the meetingMessageType when the message revolves around a meeting request.
I would also like to get the uniqueBody of the message. However, that's not provided by default. One needs to specifically ask for that field. I can do that by adding ?$select=uniqueBody to the URL.
However, that now means that I need to add the rest of the fields I want to the $select query parameter. That's not a big deal until I run into meetingMessageType. Microsoft Graph returns:
Could not find a property named 'meetingMessageType' on type 'Microsoft.OutlookServices.Message'.
What can I do to ensure I get both uniqueBody and meetingMessageType?
Try this:
$select=uniqueBody, microsoft.graph.eventMessage/meetingMessageType
Yogesh's answer is close but will result in a Only one level select is supported error.
As long as you don't care about the value of meetingMessageType, you can use this select:
$select=microsoft.graph.eventMessage, uniqueBody
You'll note that the results no longer include meetingMessageType as a property. The list however is limited to only those messages that are eventMessage, effectively giving you a result set filtered to only show meeting requests.
I am trying to learn the OData version 4 protocol and am using the Northwind database to run queries against.
OData 4 introduced the free text search with $search but the queries I've tried all fail.
A couple things I tried (with many variants):
http://services.odata.org/V4/Northwind/Northwind.svc/Customers?$search=%28City%20eq%20Berlin%29
http://services.odata.org/V4/Northwind/Northwind.svc/Customers?$search=City%20eq%20Berlin
http://services.odata.org/V4/Northwind/Northwind.svc/Customers?$search=Berlin
Error message I get is: The query parameter '$search' begins with a system-reserved '$' character but is not recognized.
The official docs don't say much here, and just reference another source for the exact format. However, the format is very cryptic to me...
From the docs, the general idea is http://host/service/Products?$search=blue OR green which seems in line with my examples. So not sure what I'm doing wrong here.
Has anyone successfully used this before and could give me an example? Thanks!
You got an error message from http://services.odata.org/V4/Northwind/Northwind.svc because this service has not been updated to support $search. ODL began to support $search in version 6.1.0. please check 6.1.0 release notes
From the spec, "The $search system query option restricts the result to include only those entities matching the specified search expression. The definition of what it means to match is dependent upon the implementation." Since the match rule is dependent on the service implementation, the service can determine which property or even properties combinations to match the search expression.
This service http://odatae2etest.azurewebsites.net/demo/DefaultService/ has simply implemented $search, and this service choose to have the first string type property to match the search expression.
So for this service, http://odatae2etest.azurewebsites.net/demo/DefaultService/ProductDetails?$search=snack is actually meant to return ProductDetails whose description contains 'snack'.
Otherwise, $search supports AND, OR, NOT operations.
I am using the Twitter Search API and I can't understand the id field of a tweet.
For example here is one: <id>tag:search.twitter.com,2005:1990561514</id>. The real ID is the final number part, right? Why doesn't Twitter already provide this in a single element? And, why is there a year of 2005on the ID field? Is that the ID of that year and the following year tweets get an ID recounted to zero? Is the ID indexed to the year?
I am asking all this stuff, because I am going to use the option of since_id to retrive new tweets. If the ID isn't really unique and depends on the year, it won't work as expected.
Thanks.
The tag is unique - but parts of it are redundant.
tag:search.twitter.com,2005:1990561514
Obviously, search.twitter.com is the URL from where you requested the document.
The ,2005 is constant. As far as I can tell, it has never changed since the service was launched. While there's no official documentation, I would guess that it refers to the ATOM specification namespace - http://www.w3.org/2005/Atom"
Finally, the long number is the Tweet's status ID. It will always be unique and can be used for the since_id.
What you will need to do is split the string, and just use the number after the colon as your ID.
I believe you are doing something wrong. If you look at all of the example results from the Twitter Search API, none of the id fields are formatted like this one you are showing.
For example:
http://search.twitter.com/search.json?q=%40twitterapi%20-via
Also, if you check out the example requests page, you will see that all of the id fields have normal formats, i.e.:
"id":122032448266698752
Update:
Now that I know you are using the atom feed, I can see where the seemingly oddly formatted element comes from. See this article on avoiding duplicates in atom feeds. Another helpful article.
Basically, atom feeds REQUIRE a unique id for each element in a feed. Some feeds use the "tag" scheme to ensure uniqueness. This format is actually pretty common in atom feeds and many frameworks use it by default. For instance, the RoR AtomFeedHelper (which might even be what Twitter uses) specifies the default format to be:
"tag:#{request.host},#{options}:#{request.fullpath.split(".")}"