Invalid shared folder ID - 409 Conflict when calling sharing/get_folder_metadata

marty-greenwell-cloudm

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.

Greg-DB

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.