You might see that the Dropbox Community team have been busy working on some major updates to the Community itself! So, here is some info on what’s changed, what’s staying the same and what you can expect from the Dropbox Community overall.
Forum Discussion
Invalid shared folder ID - 409 Conflict when calling sharing/get_folder_metadata
We are trying to migrate our app functionality to deal with the new Team Spaces accounts, but are encountering an issue when trying to access some of the folders returned from /2/sharing/list_folders
We're passing the additional Dropbox-API-Path-Root header in the request, and this is returning folders which appear to be user's root folders with shared folder IDs (these root folders are not shared to other members).
Example of a problem folder:
{
".tag":"folder",
"name":"Barnaby",
"path_lower":"/barnaby",
"path_display":"/Barnaby",
"parent_shared_folder_id":"6232378048",
"id":"id:AfDuPpgIULAAAAAAAAAACg",
"shared_folder_id":"6145433808",
"sharing_info":{
"read_only":false,
"parent_shared_folder_id":"6232378048", <--- This is the Team Space Root.
"shared_folder_id":"6145433808",
"traverse_only":false,
"no_access":false
}
},
When subsequently trying to access /2/sharing/get_folder_metadata (passing the shared_folder_id above, TeamAdmin ID and the Dropbox-API-Path-Root header), the API returns a 409 (conflict) - if the Dropbox-API-Path-Root header is excluded, the result is the same.
{
"error_summary": "invalid_id/...",
"error": {
".tag": "invalid_id"
},
"user_message": {
"locale": "en",
"text": "Invalid shared folder ID."
}
}
/2/files/get_metadata does not return an error, but there doesn't appear to be a way of identifying these as user folders under the Team Spaces root with that call (the data appears to be the same as included in the list_folders).
So is there are way of excluding these folders in the sharing/list_folders response, or a way of identifying these folders as the Team Member root folders and why does it contain a shared_folder_id if the Id is invalid? Currently the response is being caught and dealt with that way, but it's not an ideal solution.
Any help appreciated, thanks.
Thanks for the post, and apologies for the confusion. These member folders each have their own shared_folder_id value as they are each a mounted namespace in the context of the team space (even though they're not technically a "shared folder").
Unfortunately there isn't a proper way to exclude or identify these member folders as such, but I'll pass this along as a feature request. I can't promise if or when that might be implemented though.
- Greg-DB
Dropbox Staff
Thanks for the post, and apologies for the confusion. These member folders each have their own shared_folder_id value as they are each a mounted namespace in the context of the team space (even though they're not technically a "shared folder").
Unfortunately there isn't a proper way to exclude or identify these member folders as such, but I'll pass this along as a feature request. I can't promise if or when that might be implemented though.
marty-greenwell-cloudm, a temporary workaround might be exclusion of all namespaces (shared folders in quotes) with ID that participates to set of 'member_folder_id' constructed using call to /2/team/members/list_v2. 😉
Hope this helps to some extent.
Yeah, I'll have a look at that as it's probably neater than catching a 409.
Thanks for the replies.
Hi, Greg-DB ! I found approach that may be a solution but it would be awesome if you check this😊 What about comparing shared_folder_id with
home_namespace_id gotten from get_current_account response? If this ids are the same then folder is not shared. This is your personal folder. What do you think?I suppose there is no way that personal folder can become shared...
About Dropbox API Support & Feedback
Find help with the Dropbox API from other developers.
