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 · Accepted solution]

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.

[marty-greenwell-cloudm]

Yeah, I'll have a look at that as it's probably neater than catching a 409.

Thanks for the replies.

[Rolana]

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...

[Greg-DB]

@Rolana Yes, that seems like it be a reasonable workaround for identifying the member folder in the listing for the connected account. Thanks for sharing!