If I use the GET statement:
https://graph.microsoft.com/beta/sites/root/sites/ then it correctly returns a list of sub sites under my main SharePoint site. But if I add a new Team Site sub-site to my main site and then run the same command it now returns
{
"error": {
"code": "itemNotFound",
"message": "The resource could not be found.",
"innerError": {
"request-id": "604af4de-b2b5-48cf-802b-1952a7d10b42",
"date": "2017-10-07T16:56:48"
}
}
}
When I delete the new sub-site the GET statement works again. I thought it was an issue with my SharePoint site so I reported it to Office 365 SharePoint support. They get the same error. It happens with Graph v1.0 and beta but is not in the Known Issues list.
I am trying to use this to get the Drive Id of a SharePoint library on a sub-sub site but cannot get past this issue on the problem sub-site. Is there any other way of getting a Drive Id of libraries on the sub-site that Graph at present seems unable to access?
Whilst the issue of Graph not being able to return a list of more than 7 sub-sites is still there, I have found a work around to enable me to get the Drive Ids of the Drives on the sub-sites. By using the /sites: /{sitepath} option (NB the colon) I was able to go directly to the required sub-sites and then get the relevant drive Ids.
I just wanted to follow up and say we have now made some improvements that should hopefully let these kinds of queries work past 7 subsites. So hopefully this issue is now resolved.
Workaround (v1.0 only) : use
https://graph.microsoft.com/v1.0/sites?search=*
as proposed here
Related
https://graph.microsoft.com/beta/sites?search=* fails with error
{
"error": {
"code": "BadRequest",
"message": "Syntax error: character '' is not valid at position 0 in ''.",
...
}
}
However on 1.0 ((https://graph.microsoft.com/v1.0/sites?search=*)) this works fine and returns all the sites associated
Our application relies on this API to fetch all the sharepoint sites associated with a company. Is the beta behavior a bug?
The beta endpoints are currently in preview and are not yet generally available, it may be not suitable for the production environment.
If you want to fetch all the sharepoint sites, you may consider using following workaround:
There is a list in tenant-admin site that stores a cached copy of aggregated site collections data from all contentdb.
Get tenant -admin site:
Find the lists: DO_NOT_DELETE_SPLIST_TENANTADMIN_AGGREGATED_SITECO and DO_NOT_DELETE_SPLIST_TENANTADMIN_ALL_SITES_AGGREGA
These lists contain all site collection info.
One list includes personal site and another does not.
I'm getting an error in my flow when using the Grant Access to an item or folder action to grant view access to an account on a list item. I've tested this action on a SharePoint site (comm-site) configured exactly the same (99% certain) in the same tenant and it works fine. In this instance, I have a get item action on the same ID right after it, and that action works fine. The error that I get looks like this:
"body": {
"error": {
"code": 502,
"source": "flow-apim-msmanaged-na-westus2-01.azure-apim.net",
"clientRequestId": "9f16fa13-287c-441d-9331-3e7e93a5811f",
"message": "BadGateway",
"innerError": {
"status": 500,
"message": "Item does not exist. It may have been deleted by another user.\r\nclientRequestId: 9f16fa13-287c-441d-9331-3e7e93a5811f\r\nserviceRequestId: 9f16fa13-287c-441d-9331-3e7e93a5811f"
}
}
}
}
Request Ids (not sure which are important):
From inner error:
"clientRequestId": "9f16fa13-287c-441d-9331-3e7e93a5811f"
From error response header:
"SPRequestGuid": "9f16fa13-287c-441d-9331-3e7e93a5811f"
"request-id": "9f16fa13-287c-441d-9331-3e7e93a5811f"
I'm not sure if this is the sharepoint API, or graph API under the hood - but the behaviour is completely stumped me and I have no clue what is going on.
Per my test, this issue happens when we try to grant access to a list item which does not exist. So make sure the list item with the ID exist in this list.
You could add a "Get item" action and use the id, check whether you could get the item with this id.
I deleted the action and re-created it. It worked fine after that.
This was likely my mistake: I had made this flow by exporting a flow from a solution ("solution-aware flow") and importing it is a regular flow. There was a dialog that said "this is for importing normal flows, to import a flow from a solution go to solutions" which I .. disregarded. The problem was likely a result of that mis-step.
The documentation for using the MS Graph 1.0 API for accessing SharePoint files from libraries seems clear enough, if a bit indirect. My understanding is that I should be able to access the top level item of a library (and then its children via /children) by the following url scheme:
https://graph.microsoft.com/v1.0/sites/<my-tenant>.sharepoint.com:/sites/my-test-site:/drive/root
But I am only getting back an error telling me the Url is invalid:
{
"error": {
"code": "BadRequest",
"message": "Url specified is invalid.",
"innerError": {
"request-id": "08bb72aa-f3be-4df0-b253-dacc4a8fe390",
"date": "2019-07-08T16:38:07"
}
}
}
I've tried a few other url formats as well, such as specifying the drive specifically by Id /drives/<driveId>/root but had the same luck. I'm sure I am misunderstanding something. I'm using the "Path" format (:/sites/path-to-site:/ in the API because it is more natural than going and fetching an Id for everything I need to query.
You need provide global Id of the site you want to access (global Id is <hostName>,<siteCollectionId>,<siteId>).To get the global id, in you test, we can use this.
https://graph.microsoft.com/v1.0/sites/<my-tenant>.sharepoint.com:/sites/my-test-site:/
And below API gives us a list of files on a specified site's default drive:
https://graph.microsoft.com/v1.0/sites/<hostName>,<siteCollectionId>,<siteId>/drive/root/children
If you want to access files on a specific list, all you need is the id of the list:
https://graph.microsoft.com/v1.0/sites/<hostName>,<siteCollectionId>,<siteId>/lists/<listId>/drive/root/children
A week or two ago, if a user had no photo the Office 365 unified API would return metadata for a photo of size 1X1. Now it's returning the error:
{
"error": {
"code": "RequestBrokerOld-ParseUri",
"message": "Resource not found for the segment 'UserPhotos'."
}
}
Now the error has started to appear for users that do have photos. It's been getting progressively worse over the last few days, to the point that the API is unusable now. It started off as only a few missing photos, and now only 1 user photo is returned successfully out of over 250 users.
All User Photo endpoints are returning this error. E.g:
https://graph.microsoft.com/beta/me/userphotos
https://graph.microsoft.com/beta/xyz.onmicrosoft.com/users/someUserId/userphotos/48X48
https://graph.microsoft.com/beta/xyz.onmicrosoft.com/users/someUserId/userphoto/$value
The error is occuring in the sandbox too (although I can't be sure the user in the sandbox does have a photo to begin with).
Is there any known workaround or fix for this issue?
There have been some updates in the API:
http://dev.office.com/blogs/Update-3-on-Office-365-unified-API
to get to the photo, please use /photo instead of /userPhoto
From this question:
The endpoint is now called "photo" and not "userphoto"
To get the photo information you use:
api/beta/Me/photo
To get the photo you call
api/beta/Me/photo/$value
I haven't been able to get photos for a given size (eg beta/Me/photo/48x48) to work
We create all our site collections programatically with a custom site def/template. Everything works as expected, except for the crawler. It's apparently denied access to the sites. The crawl logs says:
http://server.localnetwork.lan/somesites/siteName
The object was not found. (The item
was deleted because it was either not
found or the crawler was denied access
to it.)
And in the log files I'm getting this:
08/11/2009 14:20:34.01 OWSTIMER.EXE
(0x0674)
0x1560 Search Server Common
MS Search Administration
7hmh High exception in
SearchUpgradeProvisioner Keyword
Config
System.InvalidOperationException:
jobServerSearchServiceInstance is null
at
Microsoft.Office.Server.Search.Administration.SearchUpgradeProvisioner..ctor(SearchServiceInstance
searchServiceInstance) at
Microsoft.Office.Server.Search.Administration.OSSPrimaryGathererProject.ProvisionContentSources()
If I create a site collection manually the crawler is able to access it. The same users/accounts have the same access on both sites, so that shouldn't be the issue.
The code we use to actually create the site collection looks a little like this:
SPWebApplication app = SPWebApplication.Lookup(new Uri("WebApplicationUrl"));
app.FormDigestSettings.Enabled = false;
app.Sites.Add("url", "title", "description", "language code", "SiteTemplateName", "Owner.Username", "Owner.Fullname", "Owner.Email");
app.FormDigestSettings.Enabled = true;
The code has been slightly altered to protect the innocent... ;)
Any idea what we're doing wrong?
(Please note, I'm not sure if this is a programming error or a config/setup error, so I'm cross-posting with Serverfault)
If you receive this error whilst the crawler account (the default content access account) has read permission to all your sites then you most likely need to disable the loopback check.
http://support.microsoft.com/kb/896861
http://koenvosters.wordpress.com/2009/06/15/access-denied-when-using-hostname-search-and-site-on-moss-2007/