I created an app with Files.ReadWrite.AppFolder permission only.
Request to: https://graph.microsoft.com/v1.0/drive/special/approot
Response: 404, and the AppFolder is not created in my Onedrive.
The documentation states:
"OneDrive creates your app's folder in the user's Apps folder, located in the root of the user's OneDrive, when your app makes the first call to the folder using the special folder namespace. Below are the most common calls your app can make to create the folder for the first time."
So my AppFolder should have been created and not return 404.
If I try the exact same process after adding the Files.ReadWrite.All permission the request success and return the expected response:
{
"@odata.context": "https://graph.microsoft.com/v1.0/$metadata#drive/special/$entity",
...
"folder": {
"childCount": 0
}
}
and my AppFolder is successfully created. Isn't the whole point of the Files.ReadWrite.AppFolder permissions to avoid requiring full read/write access to our users?
I too have just experienced this same issue. Requesting Files.ReadWrite.AppFolder gives me access denied when I try to access my app folder via drive/special/approot. Only when I request Files.ReadWrite.All am I finally able to access my app folder.
Like OP said, this kind of defeats the point of having a sandboxed app folder if a user needs to give me total access for me to write to it. Hoping this gets fixed.
Also, I believe the documentation here should be updated to reflect the new naming of app folder scopes: https://dev.onedrive.com/misc/appfolder.htm
onedrive.appfolder -> Files.ReadWrite.AppFolder
February 2018, still have this issue. Hope it will get fixed soon.
This issue has unfortunately changed owners a couple of times - let me get to the bottom of the status here see where we are.
For those who are seeing issues, are you trying to hit OneDrive Business or OneDrive Consumer. From what I can tell the fix for ODC should be deployed now.
@ificator had the bug with both, ODC and ODB
OK, so here's what the state of the world is:
OneDrive Consumer had an issue whereby provisioning wouldn't work when the Files.ReadWrite.AppFolder scope was the only one present, but that should now be fixed. To my knowledge OneDrive Consumer should be working as expected so please let me know if you're seeing anything that contradicts this.
OneDrive Business does not support Files.ReadWrite.AppFolder (see these remarks). We want to fix this so that it aligns with how OneDrive Consumer behaves, but it's a non-trivial change.
If support for OneDrive Business is something that you'd really like to see I'd suggest upvoting any appropriate asks on our uservoice page (or creating one if there aren't any already).
Any news about this issue?
I know it is closed but it's been few months and the uservoice task wasn't even acknowledged by the OneDrive team.
@ificator How is the status of uservoice. Looks like closed and we can't rate anymore.
By the way. If you give us developers a good way to store application information for users this scope should be working similar to personal users.
If you are an ISV and you have a product, then it is really difficult to tell customers why we need different scopes for onedrive and onedrive for business to do the same stuff.
It looks like the uservoice was created in the archive forum - I'm not exactly sure how it was done, but my guess is that there's policy in that forum that disables voting. I'll see if I can track down someone who has control over our UserVoice to find out if it's possible to move the task into the appropriate area, otherwise we'll unfortunately have to create a new one and start from the beginning vote wise.
I can say that we're aware of the desire for appfolder permissions in ODB, and it's on our backlog, but I cannot comment on timeframes.
We managed to move it back to the developer area so you should be able to vote on it again!
I'm not sure how you can close this and somehow label it "not a bug it's a yet to be implemented feature". Your public documentation doesn't even mention the fact that the appFolder scope is not available on OneDrive Business. When both share the same API but yet dependent on the kind of plan the end user chooses that same API behaves entirely differently and that behavior is undocumented, I'd be hard pressed to find anyone who would call this anything other than a bug.
Please reopen this issue, this smacks of nothing more than the overused "it's a feature, not a bug" scapegoat.
I want to remedy excessive scope requirements.
The following document describes whether ODB (OneDrive for Bussiness) supports Files.ReadWrite.AppFolder scope.
Is this true?
Is this ticket really closed?
@komikoni I think, this issue is still not fixed. Currently you can just vote on UserVoice so that it get more priority.
Is there any news on that Topic?
It looks like it works partially. It works fo me if I use the v2 auth endpoint but not with v1. Unfortunately I need v1 because currently that's the only/easiest way to use device code flow with Node.js.
Edit: This seems to be my own mistake. The permission works just fine now!
@OlliV using AppFolder permission to Enterprise/Business Accounts, or private MS Accounts?
@oFlo193o ah sorry, I didn't specify my plan. I'm using SharePoint Online which might actually have more OneDrive API features enabled than OneDrive for Business.
Most helpful comment
I'm not sure how you can close this and somehow label it "not a bug it's a yet to be implemented feature". Your public documentation doesn't even mention the fact that the appFolder scope is not available on OneDrive Business. When both share the same API but yet dependent on the kind of plan the end user chooses that same API behaves entirely differently and that behavior is undocumented, I'd be hard pressed to find anyone who would call this anything other than a bug.
Please reopen this issue, this smacks of nothing more than the overused "it's a feature, not a bug" scapegoat.